This is an archive of the discontinued LLVM Phabricator instance.

[mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`
ClosedPublic

Authored by zero9178 on Apr 23 2022, 9:36 AM.

Details

Summary

The verifier of llvm.mlir.addressof did not properly account for opaque pointers, that is, the pointer type not having an element type equal to the type of the referenced global or function. This patch fixes that by skipping the test for the element type if the pointer is opaque.

Diff Detail

Event Timeline

zero9178 created this revision.Apr 23 2022, 9:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 23 2022, 9:36 AM
zero9178 requested review of this revision.Apr 23 2022, 9:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 23 2022, 9:36 AM
rriddle accepted this revision.Apr 25 2022, 12:04 AM
rriddle added inline comments.
mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
1657–1659

Can you pull the getType() into a separate variable?

It also feels like we could wrap both of these ifs within a check for !getType().isOpaque().

mlir/test/Dialect/LLVMIR/global.mlir
76

Why do we need this?

This revision is now accepted and ready to land.Apr 25 2022, 12:04 AM
zero9178 updated this revision to Diff 424833.Apr 25 2022, 12:40 AM

Address review comments

zero9178 marked 2 inline comments as done.Apr 25 2022, 12:42 AM
zero9178 added inline comments.
mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
1657–1659

Still had to check for address space mismatch, regardless of whether the pointer is opaque, so I hoisted that check, gave it a more concrete error message and utilized an early return to skip the check of the element types

mlir/test/Dialect/LLVMIR/global.mlir
76

Think I had the intention of testing it remains a opaque pointer, but that is very much out of scope for this patch.

ftynse accepted this revision.Apr 25 2022, 1:09 AM
This revision was automatically updated to reflect the committed changes.
zero9178 marked 2 inline comments as done.