For compatibility with opaque pointers, we should be using the MLIR-level pointer element type (and translating it to LLVM), not the LLVM-level pointer element type.
Details
Diff Detail
Event Timeline
I don't think this is the right approach. If LLVM fully adopts opaque pointers, so should the LLVM dialect in MLIR. Relying on the LLVM dialect having access to element types of a pointer through MLIR types only displaces the problem.
Oh, that's interesting. I assumed it was a deliberate design decision to use typed pointer on the MLIR level, as there's no strong requirement for these to match, and typed pointers might be easier to work with on a higher level of abstraction. Of course, if MLIR would like to switch to opaque pointers as well, that sounds great to me.
I'm not familiar with MLIR myself, so I don't know what moving MLIR to opaque pointers would involve in practical terms.
There is a (very incomplete) import path from LLVM IR to the LLVM dialect, I assume this will make it a requirement for the LLVM Dialect to adopt typeless pointer "at some point" anyway right?
Even if we had the choice, the role of the LLVM dialect in MLIR is to stay as a close as possible to LLVM IR to keep the translation between the two "trivial".
Not necessarily, it's possible to create use a dummy pointer type and bitcast it appropriately for certain uses. Wouldn't be very pretty, of course.
Even if we had the choice, the role of the LLVM dialect in MLIR is to stay as a close as possible to LLVM IR to keep the translation between the two "trivial".
That makes sense.
I will look into adding support for opaque types in the LLVM dialect, and then this can be rebased.
MLIR support for opaque pointers was added in https://reviews.llvm.org/D123310 and https://reviews.llvm.org/D123792, so abandoning this revision.