[CIR] Handling of ABI relevant type information

[nikic]

cc @mmha Thanks for your talk yesterday!

I'm trying to get a handle on how ClangIR handles ABI relevant type information. What I originally wanted to figure out is how __int128 and _BitInt(128) are distinguished (which have different alignment), given that integer types are represented using only signedness and bit width: https://clang.godbolt.org/z/zGK5shafz

It turns out that the type representation is actually much lower level than I thought, and seems to correspond more to the lowered LLVM IR type (including padding fillers) rather than the original C type. However, I don't believe it is possible to perform correct calling convention lowering on such a low-level representation.

It seems like calling convention lowering is currently not implemented (in this example the structs get passed as LLVM structs), but I'm curious what the plan for handling this in the future is. Is the type system going to become higher level?

[andykaylor]

Calling convention handling is partially implemented in the incubator, but it is off by default because it triggers a lot of NYI assertions (including in the case you linked). We haven't started upstreaming the calling convention handling yet. We've got a lot of work left to do in this area, and it is likely to expose shortcomings in the pieces we have implemented.

You're also probably right that we should have a higher level type to represent _BitInt. With regards to the structure representation, we have kind of a hybrid approach. The structure definitions are, as you say, very close to LLVM IR, but when elements of the structure are accessed, you can see the element name from the source code in the cir.get_member operation. We need the low-level information to calculate things like data member offset, and the implementation is (perhaps problematically) a direct parallel to the record layout calculation used in LLVM IR generation.