-
Notifications
You must be signed in to change notification settings - Fork 248
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-pointersis 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-pointersis 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-pointersinto LLVM's-opaque-pointersinternally. - 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.