This is an archive of the discontinued LLVM Phabricator instance.

[mlir][LLVM] Convert `noalias` parameters into alias scopes during inlining
ClosedPublic

Authored by zero9178 on Jul 19 2023, 7:37 AM.

Details

Summary

Currently, inlining a function with a noalias parameter leads to a large loss of optimization potential as the noalias parameter, an important hint for alias analysis, is lost completely.

This patch fixes this with the same approach as LLVM by annotating all users of the noalias parameter with appropriate alias and noalias scope lists.
The implementation done here is not as sophisticated as LLVMs, which has more infrastructure related to escaping and captured pointers, but should work in the majority of important cases.
Any deficiency can be addressed in future patches.

Related LLVM code: https://github.com/llvm/llvm-project/blob/27ade4b554774187d2c0afcf64cd16fa6d5f619d/llvm/lib/Transforms/Utils/InlineFunction.cpp#L1090

Diff Detail

Event Timeline

zero9178 created this revision.Jul 19 2023, 7:37 AM
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
zero9178 requested review of this revision.Jul 19 2023, 7:37 AM
gysit accepted this revision.Jul 20 2023, 1:00 AM

Very nice!

LGTM modulo minor comments.

mlir/lib/Dialect/LLVMIR/IR/LLVMInlining.cpp
216

I think it is fine to not support typed pointers at this stage (AFAIK there should be no bitcasts for opaque pointers).

331

Should we use the function name as a descriptor?

346–360

Would it make sense to add this functionality to the AliasAnalysisOpInterface?

415
424–425

nit: tried to clarify the comment a bit. Feel free to use your own formulation if I got it wrong :)

mlir/test/Dialect/LLVMIR/inlining-alias-scopes.mlir
198–199

ultra nit: can you drop the double newlines here and below.

This revision is now accepted and ready to land.Jul 20 2023, 1:00 AM
definelicht added inline comments.Jul 20 2023, 1:25 AM
mlir/lib/Dialect/LLVMIR/IR/LLVMInlining.cpp
205–208
232–235
236

Why not just return the resultSet?

236–237

The documentation of these two functions makes them sound like they do pretty much exactly the same 🙂 Try renaming and extending the docstring to clarify their relationship

243

What happens if the maximum number of lookups is exceeded? Consider adding a test where this collides with another underlying object.

348–360

Maybe an llvm_unreachable default case?

771–781

Some suggestions for clarification!

zero9178 updated this revision to Diff 542417.Jul 20 2023, 3:59 AM
zero9178 marked 13 inline comments as done.

Address review comments:

  • Extend AliasAnalysisOpInterface to return pointer operands
  • Clarify and update comments
  • Other codestyle issues

PTAL @gysit @definelicht

mlir/lib/Dialect/LLVMIR/IR/LLVMInlining.cpp
243

What would happen is that the current pointer value would be returned and the code below would identify it as an unknown object where it does not know it is based on any noalias parameter or not and therefore abort putting any scope on the operation.

I ended up removing the parameter though. I originally took it from LLVM but in MLIR it has so far not been convention to put such bounds on functions and writing tests for it, I realized that its hard to write a test in a way that can't just be canonicalized easily in the future (making the bound somewhat a bad workaround for a missing canonicalization IMO).

gysit added a comment.Jul 20 2023, 5:13 AM

Can you maybe add a test case that exercises the memory intrinsics?

mlir/lib/Dialect/LLVMIR/IR/LLVMInlining.cpp
20

nit: Is the TypeSwitch still needed?

zero9178 updated this revision to Diff 542445.Jul 20 2023, 5:27 AM
  • Add tests exercising all operations with alias scopes
  • Fix bug discovered through the new test which mistakenly created empty scope lists
zero9178 updated this revision to Diff 542448.Jul 20 2023, 5:28 AM

remove redundant typeswitch include

zero9178 marked an inline comment as done.Jul 20 2023, 5:28 AM
definelicht accepted this revision.Jul 20 2023, 5:37 AM

LGTM with some grammar fixes 🤓

mlir/lib/Dialect/LLVMIR/IR/LLVMInlining.cpp
205–207

Instead of "best effort" and "best result", write concretely what the semantics actually are (trace back until the end or an op it cannot resolve).

226–230

I would remove the "best effort" sentence altogether, since it doesn't really add much (the first word is already "attempts"). If you want you can add a sentence on concretely what happens if it doesn't resolve a path.

771–781
gysit accepted this revision.Jul 20 2023, 5:39 AM

Looks even more LGTM!

This revision was landed with ongoing or failed builds.Jul 20 2023, 6:05 AM
This revision was automatically updated to reflect the committed changes.
zero9178 marked 3 inline comments as done.