llvm / clangir

A new (MLIR based) high-level IR for clang.
https://clangir.org
Other
333 stars 89 forks source link

Move struct field name from callsite to type #150

Open sitio-couto opened 1 year ago

sitio-couto commented 1 year ago

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.

Originally posted by @bcardosolopes in https://github.com/llvm/clangir/pull/148#pullrequestreview-1511701503

PragmaTwice commented 3 months 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 : )

PragmaTwice commented 3 months ago

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