After https://reviews.llvm.org/D153092, for targets that use a non-default AS for globals, an "interesting" situation arises around typeid and its paired type, type_info:
- on the AST level, the type_info interface is defined with default / generic addresses, be it for function arguments, or for this;
- in IR, type_info values are globals, and thus pointers to type_info values are pointers to global
This leads to a mismatch between the function signature / formal type of the argument, and its actual type. Currently we try to handle such mismatches via bitcast, but that is wrong in this case, since an ascast is required. However, I'm not convinced this is the right way to address it, I've just not found a better / less noisy one (yet?); the other alternative would be to special case codegen for typeinfo itself, and adjust the IR function signatures there. That's less centralised and doesn't actually seem correct, since type_info has a C++(mangled) interface, and we'd be basically lying about the type. Hopefully I'm missing some obvious and significantly more tidy solution - hence the RFC.
you can also just unconditionally call CreateAddrSpaceCast and let it no-op if the types match