Skip to content

Translate -emit-opaque-pointers to LLVM's -opaque-pointers (LLVM 16) #3250

Open
@karolzwolak

Description

@karolzwolak

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions