You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 for struct_element_addr we could print the names for convenience, by just looking at the type.
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.
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 #148 (review)
The text was updated successfully, but these errors were encountered: