Interesting, thank you. I expected both answers to be “unchanged” so was surprised by the zero extend in the legaliser.

The motivation here is that it’s faster for us to load N bytes, apply whatever masks are necessary to reproduce the truncating store then store all N bytes. This is only a good plan if there’s no change to the semantics

Are scalar integer types zero extended to the next multiple of 8 or to the next power of 2 greater than 7? For example, i17 => i24 or i17 => i32?

I think this means truncating stores of vector types will introduce zero bits at the end of each element instead grouping all the zeros at the end. For example, <i6 63, i6 63> writes to sixteen bits as 0b0011111100111111, not as 0b0000111111111111?

Thanks!

Jon

Interesting, thank you. I expected both answers to be "unchanged" so was surprised by the zero extend in the legaliser.

The motivation here is that it's faster for us to load N bytes, apply whatever masks are necessary to reproduce the truncating store then store all N bytes. This is only a good plan if there's no change to the semantics

See LLVM Language Reference Manual — LLVM 18.0.0git documentation . In general, you have to be careful to avoid data races, but that might not apply to your target.

Are scalar integer types zero extended to the next multiple of 8 or to the next power of 2 greater than 7? For example, i17 => i24 or i17 => i32?

Multiple of 8.

I think this means truncating stores of vector types will introduce zero bits at the end of each element instead grouping all the zeros at the end. For example, <i6 63, i6 63> writes to sixteen bits as 0b0011111100111111, not as 0b0000111111111111?

Vector types are tightly packed, so <8 x i1> is 1 byte, not 8 bytes.

-Eli