This allows for checking if a given operation may modify/reference/or both a given value. Right now this API is limited to Value based memory locations, but we should expand this to include attribute based values at some point. This is left for future work because the rest of the AliasAnalysis API also has this restriction.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Analysis/AliasAnalysis/LocalAliasAnalysis.cpp | ||
---|---|---|
346 | This looks like it could get very expensive for multiple nested scf.if ops. It even looks like it could go quadratic for certain kinds of query patterns (e.g. calling getModRef on each operation in a function) |
mlir/include/mlir/Analysis/AliasAnalysis.h | ||
---|---|---|
94 | The class doc comment refers to memory access and memory alone, while an aliasing relation is being referred to here. I think a line or two is missing on the connection in the class doc comment. | |
150–155 | Comment copied. | |
mlir/lib/Analysis/AliasAnalysis/LocalAliasAnalysis.cpp | ||
198 | ? |
Could you document the differences to:
https://github.com/llvm/llvm-project/blob/cc58e8918b70d5698ec06c0b6e4c6e4c27971870/llvm/include/llvm/Analysis/AliasAnalysis.h#L148
for future reference?
Similar to ModRefInfo, you used an unscoped enum to facilitate the logical operations. Is a design based on a type-safe scoped enum too verbose?
IMO yeah. Just switched to using static creation methods, given that access to the kind isn't really necessary anyways. I'll switch AliasResult to do the same in a followup.
mlir/lib/Analysis/AliasAnalysis/LocalAliasAnalysis.cpp | ||
---|---|---|
198 | It's marking what the section corresponds to, given that I use the same LocalAliasAnalysis below. | |
346 | Yeah, I agree. For now just added a TODO, will handle as necessary in a followup. |
The class doc comment refers to memory access and memory alone, while an aliasing relation is being referred to here. I think a line or two is missing on the connection in the class doc comment.