[clang] [CIR] Update bit-field representation (PR #221030)

[Andy Kaylor via cfe-commits]

andykaylor wrote:

> So I don't see any changes to ConstRecordLayout/lowering of initializers, are we just leaving those alone? I guess that sorta makes sense...

The constant record initializers stay the same because the bitfield access unit represents the same type that it did before the change.

> I don't see any 'get-member' changes either though. I would expect (perhaps not today?) that our accesses in CIR do NOT do the bit-fiddling-math and instead do just 'get-member' with an additional index, then handle bit-fiddling during lowering. WDYT?

We have a separate `cir.get_bitfield` that abstracts all of the details of the bit manipulation. It's not affected by this change. The type returned by `cir.get_member` is a pointer to the storage type of the bitfield access unit rather than a pointer to the bitfield type. A bitfield read looks like this (before and after this PR):

```
    %3 = cir.get_member %2[1] {name = "bf2"} : !cir.ptr<!rec_S> -> !cir.ptr<!u32i> loc(#loc7)
    %4 = cir.get_bitfield align(4) (#bfi_bf2, %3 : !cir.ptr<!u32i>) -> !s32i loc(#loc8)
```
https://godbolt.org/z/93o4TKxcz

I think we'll be able to simplify `cir.get_bitfield` after this change lands, but I didn't want to do it here, given how huge this is already. The `cir.bitfield_info` attribute shown above contains information that's already contained in the bitfield type. The only thing it adds is the name of the field. So, we should be able to have `cir.get_member` return a pointer to the bitfield type rather than the storage type and then use that in `cir.get_bitfield` which would only need the index (or offset?) being read and the name of the field.

https://github.com/llvm/llvm-project/pull/221030