This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] Avoid LLVM pointer element type accesses in LLVMOps.td
AbandonedPublic

Authored by nikic on Mar 30 2022, 1:25 AM.

Details

Reviewers
ftynse
mehdi_amini
Group Reviewers
Restricted Project
Summary

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.

Diff Detail

Event Timeline

nikic created this revision.Mar 30 2022, 1:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 30 2022, 1:25 AM
nikic requested review of this revision.Mar 30 2022, 1:25 AM
ftynse requested changes to this revision.Mar 30 2022, 8:10 AM

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.

This revision now requires changes to proceed.Mar 30 2022, 8:10 AM
nikic added a comment.Mar 31 2022, 2:04 AM

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".

nikic added a comment.Apr 1 2022, 5:17 AM

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?

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.

ftynse added a comment.Apr 6 2022, 5:06 AM

I will look into adding support for opaque types in the LLVM dialect, and then this can be rebased.

nikic abandoned this revision.Apr 19 2022, 2:48 AM

MLIR support for opaque pointers was added in https://reviews.llvm.org/D123310 and https://reviews.llvm.org/D123792, so abandoning this revision.