Description
Please correct me if I'm wrong, but the emit-opaque-pointers
flag seems redundant. It overlaps with the existing LLVM -opaque-pointers
flag:
-opaque-pointers
is provided by LLVM, enabled by default, and controls whether opaque or typed pointers are used in both directions (LLVM to SPIR-V and SPIR-V to LLVM).emit-opaque-pointers
is a hidden flag we define, and it only affects the SPIR-V to LLVM direction.
We don't maintain -opaque-pointers
ourselves — it’s part of LLVM. Having a second flag with overlapping semantics introduces complexity and inconsistency.
On Inconsistent Behavior
Right now, opaque pointers are used when translating LLVM to SPIR-V, but typed pointers are used when going from SPIR-V to LLVM. This inconsistency can lead to confusing behavior, especially since LLVM doesn't verify that the IR matches the pointer type mode. If there's a mismatch, it can result in undefined behavior or subtle bugs.
Also, we can't safely enable emit-opaque-pointers
by default. An assertion in LLVMContext prevents disabling opaque pointers once they’ve been enabled. So if the flag defaults to true and someone tries to disable it, it will crash.
Proposal
Rather than removing emit-opaque-pointers
outright (which would be a breaking change even though it's hidden), we could:
- Translate
emit-opaque-pointers
into LLVM's-opaque-pointers
internally. - Always enable opaque pointers by default to match LLVM's default and future behavior.
- Ensure we use opaque pointers by default in both translation directions, including SPIR-V to LLVM.
- Disallow setting both flags to different values at the same time.
This would avoid configuration inconsistencies while preserving backward compatibility.
Open to other suggestions, but this seems like a clean, non-breaking step in the right direction.