Fix for https://bugs.llvm.org/show_bug.cgi?id=39282. Scoped noalias metadata inside a loop might only be applicable within an iteration, so we should duplicate it into distinct domains when unrolling a loop.
Details
- Reviewers
- None
Diff Detail
Event Timeline
I think this makes sense, though it will probably only mitigate the problem.
llvm/lib/Transforms/Utils/LoopUnroll.cpp | ||
---|---|---|
262 | Nit: Don't we have a range based version of this? | |
273 | Do you pass MD by value on purpose? Also consider passing the return value by reference, though I doubt it makes much of a difference. | |
285 | Nit: hoist and use clear, according to the programmers manual (or some other document we have). | |
286 | Nit: range again? | |
304 | Could you add some documentation here and above please. | |
307 | Nit: range & auto? |
It would make sense to add comments in the code to explain _why_ this is needed and why it is safe to do.
note: the transformation should be correct, as the unrolled version might now 'alias' with usages of the original scopes that are outside the loop.
Extract ScopedAliasMetadataCloner utility to share between inlining and loop unrolling. Tidy up the code with range based loops etc.
I've now updated this to introduce a common utility (ScopedAliasMetadataCloner) that can handle essentially the same task in inlining and loop unrolling. If that looks reasonable, I can commit the utility separately from the new usage in LoopUnroll.
@jeroen.dobbelaere: Yeah, I'm aware of that. However, the full restrict patches are a large change that has stalled for a long time, so I think we need to address the miscomples in a simple way in the meantime. I was also wondering if it might not make sense to split up the full restrict patches in a way that addresses individual problems without having to land the full machinery in one go. For example, by first introducing the noalias.decl function only, which is I believe the only part that's relevant for this particular problem.
I was hoping to be further in the review process by now.. but getting somebody to review/help reviewing the documentation patch already seems to be hard :(
Next week, I can put some effort into prepare a patch with the 'llvm.noalias.decl', together with the necessary cloning for loop unroll.
That should help you, by fixing this problem. It should also help the full restrict patches, by already incorporating part of it in the main llvm.
Maybe this is something we can discuss tomorrow in the llvm alias analysis technical call (Nov 3, noon central time) ?
( http://lists.llvm.org/pipermail/llvm-dev/2020-November/146311.html )
[..]
Note: the correct time of the LLVM Alias Analysis Technical call is 12am (noon). See http://lists.llvm.org/pipermail/llvm-dev/2020-November/146311.html
As discussed during the LLVM Alias Analysis technical call, I will work this week on a fix using `llvm.noalias.decl`.
Just an update: I am finalizing an alternative version using the @llvm.noalias.decl intrinsic. Should be there later today.
Nit: Don't we have a range based version of this?