bcardosolopes wrote:
> Why are we representing each member of a union individually but packing
> bitfields away in integer fields?
As you noticed, we went higher level for unions (kept the other types around)
but didn't for bitfields. I don't see it as inconsistent because in my point of
view they are orthogonal (even though you can compose them). Bitfields can get
tricky, so we decided to go the "fast path" that would minimize differences
between OG and CIRGen and be more like LLVM until we get a good use case for a
richer representation (so that the design could incorporate real needs). Note
that I'm not against improving it, but we just decided not to spend time there
with the resources we had.
> What would you think of something like this?
>
> `!cir.record<struct "S" {!s32i, !cir.bitfield<2>, !cir.bitfield<5>,
> !cir.bitfield<7>}`
>
> That puts a bit more burden on the `RecordType::getElementOffset`
> implementation, but I think it would let us defer some of the details to
> lowering.
I'm fine with something like this, thanks for pushing it. Good thing we already
have good tests for bitfields, which might help a bunch with bulletproofing the
new representation - so my suggestion is to it first in the incubator to
leverage the existing LLVM output checks.
@gitoleg you have worked a lot on bitfields, do you have any feedback here or
extra suggestions?
https://github.com/llvm/llvm-project/pull/142041
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
