alias analysis between C and Chapel with LLVM backend

[mppf]

Currently, the C backend uses alias analysis rules that integrate Chapel types with C types. However, the LLVM backend uses two separate TBAA trees for C types and for Chapel types.

Naturally, we do not want to restrict the LLVM backend to use C aliasing rules. However, the LLVM passes conservatively assume anything from separate TBAA trees may alias. This caused a performance issue for --llvm (#8060).

A reproducer would look like this:

• Chapel code has a loop in it
• loop includes loads and stores on Chapel types
• loop includes a call to an inline C function that includes a load from a C pointer. This load is loop-invariant.

Then, observe that the loop-invariant load from the C code will not be hoisted, because the TBAA metadata says it may alias the store generated by the Chapel code.

Could we generate the TBAA tree in an integrated way with the C TBAA tree?

[mppf]

pinging @dmk42 - curious if you have an opinion about this

[dmk42]

Yes, when I was doing the TBAA work, I wondered whether this would ever become a problem. I ended up structuring Chapel's TBAA metadata in such a way that it shouldn't be too hard to integrate them, probably not more than one sprint.

[Edit] On second thought, I remember why I didn't actually integrate them before. The basic types will be difficult to get right (Chapel types that translate to C integer types, float, complex, etc.). Pointers are a little easier to integrate.

I still think it can be done, though.

[Edit again] OK, now I remember the other reason I didn't integrate them before. Then Chapel pointers would have to follow C's aliasing rules, which may cause performance regressions.

Now I'm thinking that this is a big experiment. It may be worth trying, though.