This is an archive of the discontinued LLVM Phabricator instance.

[LoopUnroll] Duplicate noalias metadata
AbandonedPublic

Authored by nikic on Oct 24 2020, 1:58 PM.

Details

Reviewers
None
Summary

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.

Diff Detail

Event Timeline

nikic created this revision.Oct 24 2020, 1:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 24 2020, 1:58 PM
nikic requested review of this revision.Oct 24 2020, 1:58 PM

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.

  • aka, this will be a pessimization for some use cases (those where the cloning should not be needed)
  • for reference, D68510 is the patch in the 'full restrict patchset' (D68484) that adds similar, but more complete suport.
Meinersbur added inline comments.
llvm/test/Transforms/LoopUnroll/noalias.ll
3

For robustness, the test case should specify the unroll factor, e.g. -unroll-count=4

48–59

User regex to match MDNodes?

nikic updated this revision to Diff 302079.Oct 31 2020, 3:55 AM

Extract ScopedAliasMetadataCloner utility to share between inlining and loop unrolling. Tidy up the code with range based loops etc.

nikic added a comment.Oct 31 2020, 4:06 AM

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.

jeroen.dobbelaere added a comment.EditedNov 2 2020, 5:44 AM

@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

uenoku added a subscriber: uenoku.Nov 3 2020, 9:44 AM

As discussed during the LLVM Alias Analysis technical call, I will work this week on a fix using `llvm.noalias.decl`.

MSxDOS added a subscriber: MSxDOS.Dec 4 2020, 2:24 PM
lzutao added a subscriber: lzutao.Dec 6 2020, 4:47 PM

Just an update: I am finalizing an alternative version using the @llvm.noalias.decl intrinsic. Should be there later today.

penzn added a subscriber: penzn.Jan 5 2021, 10:09 AM
nikic added a comment.Jan 24 2021, 1:50 AM

Abandoning this in favor of D92887.

nikic abandoned this revision.Jan 31 2021, 9:10 AM