Open sitio-couto opened 1 year ago
It seems that struct_element_addr
has been renamed to get_member
, but the issue still exists.
If no one has already started working on it, I will look into it soon : )
I have checked the issue and it appears challenging to handle when dealing with bitfields.
The bitfield information in cir.struct
has already been erased, making it difficult to map each field type in cir.struct
to the data member's name.
It seems to me that one possible way is to maintain data member types in cir.struct with bitfield information, and transform it to the current form when dumping LLVM IR, e.g.
// SOURCE CODE
struct A {
int a;
int b : 1;
int c : 1;
};
// AS IS:
!ty_22A22 = !cir.struct<struct "A" {!cir.int<s, 32>, !cir.int<u, 8>}
// TO BE: (not real CIR code)
!ty_22A22 = !cir.struct<struct "A" {!cir.int<s, 32> a, !cir.int<s, 32> BITFIELD(1) b, !cir.int<s, 32> BITFIELD(1) c}
But in this way, the handling of memory location / memory layout in CIR will be a bit tricky.
Another way might be to keep the current approach and put the data member name in cir.get_member
.
Any suggestions for this? 🤔 cc @bcardosolopes @sitio-couto
This is great, glad you beat me to it, we needed this to happen sooner or later.
Brain dump: keeping the name at the "callsite" is a bit silly, we should probably store these names into the
cir.struct
themselves and when we create a pretty printer forstruct_element_addr
we could print the names for convenience, by just looking at the type.Originally posted by @bcardosolopes in https://github.com/llvm/clangir/pull/148#pullrequestreview-1511701503