If we have unroll and jammed a loop based on metadata, make sure we
remove the now consumed unroll_and_jam metadata.
Details
- Reviewers
SjoerdMeijer hfinkel Meinersbur
Diff Detail
Event Timeline
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. |
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"? |
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. |
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 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). |
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.