Open Laity000 opened 3 months ago
Should the type of RTTI pointers be cir.ptr<!s8i> instead of cir.ptr<!u8i>?
The idea when cir.ptr<!u8i>
was first introduced was to basically mean cir.ptr<!void>
, which we didn't have at the time. This is more about having a canonical representation for these "opaque" things that we store. Changing might sound like a reasonable approach, but it's possible whenever these values are needed they are being casted to the appropriated type, did you check that? I'm also against changing all of it to s8, ptrs not related to casted offsets should still be u8, and it's just super confusing to readers to make them s8.
llvm ir 12.0.1
This is old, not even using opaque pointers. As a general advice, I suggest you base up your investigations on top of clang-18 or trunk.
So, similar to LLVM IR, Should the insertion of global variables be centralized at the beginning of the module?
We should do a better job, for sure. LLVM codegen has a somewhat lazy approach for global variables, so it's not exactly like you are pointing out. Any improvements here should definitely account for a similar approach from the original LLVM codegen.
Thanks for pointing out (1) and (2), as you noticed, they are pre-requisites into implementing multiple inheritance.
Thank you for your response. Please review the discussion about the vtable type in this PR. #569
I found that CIR currently does not support multiple inheritance, so I am trying to support this feature. However, I encountered two issues:
cir.ptr<!s8i>
instead ofcir.ptr<!u8i>
?llvm ir 12.0.1:
The modified cir:
applyReplacements()
, which may cause vtable symbols to not be found in the symbol table for cir2mlir lowering (for caseclang/test/CIR/CodeGen/vtable-rtti.cpp
). So, similar to LLVM IR, Should the insertion of global variables be centralized at the beginning of the module?