Clang typed-pointer IR and LLVM opt opaque-pointer bitcode interoperability
0 reputation · 24 Aug 2021, 23:56 UTC
Goal
Determine whether LLVM IR emitted by Clang using typed pointer syntax can be parsed and optimized by the LLVM middle-end in a release where opaque pointers are the default representation, and whether mixing typed and opaque pointer constructs in the same module is accepted or rejected.
Constraints
The opaque-pointer migration changed pointer syntax in IR, bitcode, and many passes. Acceptance of typed versus opaque pointers is a toolchain policy decision that can change between LLVM releases, so behavior is not guaranteed by the C language semantics alone. Bitcode or IR produced with different pointer settings may fail to parse or optimize differently, particularly in LTO where Clang and LLVM tools must agree on the same representation.
Assume one LLVM build provides Clang, the LLVM assembler and disassembler, and the optimizer; results from other versions apply only to those exact versions.
- Does the release accept typed pointer IR as valid input, emit opaque pointers by default, or reject mixed typed and opaque constructs?
- Can bitcode containing typed pointers round-trip through the LLVM assembler and disassembler without parse errors in that release?
- Does an optimization pipeline produce identical results for typed and opaque pointer forms of the same function?