@swift-ci create

This is IRGen's purview. We don't currently do bit-packing for tuples or structs. It's unlikely we'd ever be able to bit-pack tuples due to abstraction limitations (our runtime value witness tables can't handle overlapping layout, and someone might use (Int120, Int8) as an unspecialized `(T, U)`), but a struct might one day be able to overlap fields like this.

SR-3723 looks like it covers efficient struct layout.

Well, I wasn't really after tuples; that's just how I demonstrated the issue. I actually wanted it to pack in a struct, and the alternative requires resorting to really dangerous `unsafeBitCast`s.

Also, why do you call this overlapping?

It's overlapping because Int120 is going to be treated as having 128 bits of 32- or 64-bit-aligned storage, and the Int8 would be superimposed into unused space in that representation.

That sort of begs the question. Why is Int120 going to be treated as having 128 bits? That doesn't seem obvious at all.

Note that this works:

struct X { var a: (Int64,Int32,Int16,Int8), b: UInt8 }
assert(MemoryLayout<X>.size * 8 == 128)

The unhelpful glib answer would be "because LLVM says so". If you were going to do arithmetic on Int120 and not just use it as bit storage, then it's going to be more efficient to do so in register-sized chunks without having to mind the odd-sized final chunk.

Thanks for the unhelpful glib answer, my friend!

Of course I would extend the thing to Int128 when doing any arithmetic, though. The point of using something like Builtin.Int120 is to control storage.

Well, the original purpose was only to have something to map to the underlying llvm integer types. If you want to control storage, it seems to me you probably also want to control alignment somehow, and integer builtins aren't great for that. Maybe we could have a `Builtin.AlignedStorageSS_AA` to summon storage of size SS/alignment AA.

That would be great, but I'd still need a reasonable way to get bits out of it, so it had better be zext-able to some Int type at least. Or maybe just Builtin.reinterpretCast-able to an IntSS.

Seems there's still some life in this discussion

I discussed this today with a few people and we agreed that if we want to add support for low-level bit packing in the future, it would not use the Builtin.Int* types.

I don't see how "we wouldn't using Builtin.Int* to do low-level bit packing" implies "we won't do a better way to do low-level bit-packing"