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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
