Add struct types to Halide

[alexreinking]

This PR adds struct types to Halide. This allows for inputs and outputs to be defined in terms of popular wire formats, even if they aren't prepared for efficient computation. For example, you can define GGML's q5_0 and q8_0 formats like so:

Type q5_0 = Type::Struct({{"d", Float(16)}, {"qh", UInt(32)}, {"qs", UInt(8), 16}});
Type q8_0 = Type::Struct({{"d", Float(16)}, {"qs", Int(8), 32}});

Then you can write a pipeline that consumes them:

ImageParam x{q4_0_type(), 1, "x"};
ImageParam y{q8_0_type(), 1, "y"};

Var b("b"), k("k"), u("u");
RDom r(0, x.dim(0).extent(), 0, 32, "r");  // block, quant

// Dequantize one 4-bit weight to float: quant k is a nibble of the
// packed byte k % 16 -- its low nibble for k < 16, its high nibble
// otherwise -- biased by -8 to signed [-8, 7], times the block delta.
Expr nib = field(x(b), "qs")[k % 16];  // uint8
Func x_wt("x_wt");
x_wt(k, b) = cast<float>(field(x(b), "d")) * 
             (cast<int32_t>(select(k < 16, nib % 16, nib / 16)) - 8);

// Dequantize one int8 activation to float: quant k is int8 k, times the
// block delta.
Func y_wt("y_wt");
y_wt(k, b) = cast<float>(field(y(b), "d")) * 
             cast<int32_t>(field(y(b), "qs")[k]);

// Dequantize each side and sum every product.
Func qdot{"qdot"};
qdot() = 0.0f;
qdot() += x_wt(r[1], r[0]) * y_wt(r[1], r[0]);

As you can see, struct types support both individual elements, as well as fixed-size array elements. Fields are accessed with a named field(expr, "name") intrinsic. The tests include additional cases for struct-typed fields and output structs.

This adjusts the Type and halide_type_t representations in the following ways:

1. Type: like Handle, a Struct type has a compile-time known field layout.
2. halide_type_t: structs get their own kind, and the reserved field records the number of bytes in the struct.

All layouts are expected to be packed. No padding is inserted around or in between field elements.

Breaking changes

None—it's a new feature.

Checklist

• Tests added or updated (not required for docs, CI config, or typo fixes)
• Documentation updated (if public API changed)
• Python bindings updated (if public API changed)
• Benchmarks are included here if the change is intended to affect performance.
• Commits include AI attribution where applicable (see Code of Conduct)

[codecov]

Codecov Report

❌ Patch coverage is 65.60935% with 206 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.11%. Comparing base (c3cc67b) to head (326c7e6).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/LowerStructTypes.cpp	69.41%	43 Missing and 20 partials ⚠️
src/IROperator.cpp	59.23%	34 Missing and 19 partials ⚠️
src/Type.cpp	71.92%	10 Missing and 22 partials ⚠️
src/IRPrinter.cpp	0.00%	10 Missing and 2 partials ⚠️
src/CodeGen_Vulkan_Dev.cpp	0.00%	10 Missing ⚠️
src/CodeGen_D3D12Compute_Dev.cpp	0.00%	8 Missing ⚠️
src/Type.h	80.00%	2 Missing and 3 partials ⚠️
src/FuseGPUThreadLoops.cpp	0.00%	3 Missing and 1 partial ⚠️
src/Deserialization.cpp	81.25%	1 Missing and 2 partials ⚠️
src/IROperator.h	57.14%	3 Missing ⚠️
... and 8 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9416      +/-   ##
==========================================
- Coverage   70.11%   70.11%   -0.01%     
==========================================
  Files         261      262       +1     
  Lines       79940    80508     +568     
  Branches    19478    19637     +159     
==========================================
+ Hits        56052    56450     +398     
- Misses      18047    18173     +126     
- Partials     5841     5885      +44     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[abadams]

I think this risks forwarding lets that contain loads across stores that clobber them, e.g. in the obscure case that you have an update def on a Tuple-valued Func where one tuple component is a struct and there is cross-talk between tuple elements. A potential solution discussed in person is turning this:

let foo = some struct
...

... foo.field1 ... foo.field2 ...

into this:

let foo_field1 = lowered rhs of the original let for field1
let foo_field2 = lowered rhs of the original let for field2

...

... foo_field1 ... foo_field2 ...

[abadams]

It would be simpler (if the vectorization pass allows it) to lower it to a single load of a byte vector + a reinterpret to a scalar. In the common case of a struct size and field offset that are a multiple of the scalar size, it could just be a flat load of the scalar type.

[abadams]

Comments analogous to my load ones apply here. The stores could be byte-vector stores for unaligned or scalar stores for aligned fields, instead of storing one byte at a time.

[abadams]

Suggest a bool aligned, which is true when its offset in the containing struct is a multiple of its scalar size and the containing struct's total size is also a multiple of its scalar size. This could also be computed as needed at the usage site, or as a helper method on StructTypeInfo if the same StructField can be used in multiple StructTypeInfos

[abadams]

Given that it's no longer reserved for future use, I recommend changing the name, e.g. to "info"

[abadams]

Suggested alternative name: matches_buffer_abi_type

[abadams]

Please add a tuple-of-structs test where there's an update definition that involves cross-talk between tuple elements (as a regression test for the potential issue pointed out above)

[abadams]

This refers directly to a path from another PR

[abadams]

Oops, misundersood. Please add a github link or something for ggml