This is an archive of the discontinued LLVM Phabricator instance.

[UnJ] Ensure unroll_and_jam metadata is removed once consumed.
Needs ReviewPublic

Authored by dmgreen on Aug 14 2018, 4:33 AM.

Details

Summary

If we have unroll and jammed a loop based on metadata, make sure we
remove the now consumed unroll_and_jam metadata.

Diff Detail

Event Timeline

dmgreen created this revision.Aug 14 2018, 4:33 AM
hiraditya added inline comments.Aug 14 2018, 5:32 AM
include/llvm/Analysis/LoopInfo.h
568

I think we can add the Prefix at the caller all the time, a default value of "llvm.loop.unroll." may not be general. It seems renaming the function to reflect a more general semantics like: setLoopAlreadyTransformed and then renaming appropriate local variables would be a good improvement.

Meinersbur added inline comments.Aug 14 2018, 3:04 PM
include/llvm/Analysis/LoopInfo.h
568

There are a lot of inconsistencies in handling metadata. LoopVectorizer adds llvm.loop.isvectorized instead of removing its metadata. LoopDistribution doesn't care about remaining metadata at all.

I am trying to add a bit of uniformness in D49281. If a followup attribute is set, it drops all loop preexisting metadata since the transformed loop is a different loop than the loop the metadata is for.

LoopUnroll and LoopUnrollAndJam are strangely intertwined. Some setting to LoopUnroll also apply on LoopUnrollAndJam. Not an ideal situation.

If we go for a different name, I'd suggest forceDisableTransformation or similar. setLoopAlreadyUnrolled sounds like it does just sets a flag, but does more.

lib/Analysis/LoopInfo.cpp
295

[serious] This is intended to disable unroll-and-jam as well? why not using Prefix + "disable"?

dmgreen added inline comments.Aug 19 2018, 2:31 AM
include/llvm/Analysis/LoopInfo.h
568

As this is only used for unroll and unroll and jam, I think setLoopAlreadyUnrolled still fits, at least for the moment.

I think that once it's in it would be good to move towards the function in D49281, which should be able to handle this in a more generic way. This patch is an attempt to make that work better and not produce warnings for unrolled and jammed loops.

lib/Analysis/LoopInfo.cpp
295

Yep, it was intended. But with Prefix may be better.

llvm.loop.unroll.disable also disables unroll-and-jam if there is no unroll_and_jam metadata. As we remove all the unroll_and_jam metadata above, this will disable any further unrolling or unroll-and-jamming.

Whether it is entirely necessary to disable unroll here, I'm not 100% sure of. If a user does:

#pragma unroll_and_jam(2)
for ..
  #pragma unroll
  for ..

I'd expect it to be unroll-and-jammed by 2, but not then unrolled more. Using "llvm.loop.unroll.disable" will disable any follow-on unroll or unroll-and-jam.

Meinersbur added inline comments.Aug 20 2018, 9:39 AM
lib/Analysis/LoopInfo.cpp
295

I'd prefer to minimize the interaction between different passes. I am understanding unroll-and-jam as a pass orthogonal to unroll. I have no model in what why their metadata interact, and I'd prefer if it was predictable.

At the very least, please add a comment about the intention; it look too much like something has been forgotten.

I'd expect it to be unroll-and-jammed by 2, but not then unrolled more. Using "llvm.loop.unroll.disable" will disable any follow-on unroll or unroll-and-jam.

I don't understand. This this patch is already using llvm.loop.unroll.disable and disables further unrolling of the outer loop. There is no effect on the inner loop. That is, your example works as expected (I tried).