This is an archive of the discontinued LLVM Phabricator instance.

Rewrite part of how loop ID is obtained.
Needs ReviewPublic

Authored by trentxintong on Jan 15 2017, 5:36 PM.

Details

Summary

If a loop has multiple backedges and all of them have the same metadata.
we return that metadata. Otherwise we return nullptr.

Without the patch, we search through all blocks in the loop, this is an
overkill and more importantly we bail on the first block that is either a latch
without metadata or *not* a latch at all. we should not bail on non-latch block.

Event Timeline

trentxintong retitled this revision from to Rewrite part of how loop ID is obtained..
trentxintong updated this object.
trentxintong added a subscriber: llvm-commits.
sanjoy edited edge metadata.Jan 16 2017, 9:09 AM

Code-wise this looks fine, but the "If a loop has multiple backedges and all of them have the same metadata we return that metadata. Otherwise we return nullptr." bit should be documented in the LangRef. I'll also ask you to please wait for someone familiar with how LLVM uses !llvm.loop to give a final go head before checking this in.

lib/Analysis/LoopInfo.cpp
223

s/I/BB/

unittests/Analysis/LoopInfoTest.cpp
103

You can reduce some of this boilerplate by a runWithLoopInfo helper, as in: https://github.com/llvm-mirror/llvm/blob/master/unittests/Analysis/ScalarEvolutionTest.cpp#L54

Code-wise this looks fine, but the "If a loop has multiple backedges and all of them have the same metadata we return that metadata. Otherwise we return nullptr." bit should be documented in the LangRef. I'll also ask you to please wait for someone familiar with how LLVM uses !llvm.loop to give a final go head before checking this in.

Thanks for the review. I will wait for @hfinkel to give the final approval.

hfinkel edited edge metadata.Jan 16 2017, 9:28 AM

Code-wise this looks fine, but the "If a loop has multiple backedges and all of them have the same metadata we return that metadata. Otherwise we return nullptr." bit should be documented in the LangRef. I'll also ask you to please wait for someone familiar with how LLVM uses !llvm.loop to give a final go head before checking this in.

Thanks for the review. I will wait for @hfinkel to give the final approval.

I think that this makes sense. I agree with Sanjoy that we should make sure that the LangRef reflects what we actually do here.

lib/Analysis/LoopInfo.cpp
223

You should be able to use a range-based for here, something like:

for (auto &BB : predecessors(H)) {

Code-wise this looks fine, but the "If a loop has multiple backedges and all of them have the same metadata we return that metadata. Otherwise we return nullptr." bit should be documented in the LangRef. I'll also ask you to please wait for someone familiar with how LLVM uses !llvm.loop to give a final go head before checking this in.

Thanks for the review. I will wait for @hfinkel to give the final approval.

I think that this makes sense. I agree with Sanjoy that we should make sure that the LangRef reflects what we actually do here.

To be honest, I am a little bit confused now. Originally, I created this patch because according to getLoopID()'s comment, we should return the null if there are multiple latches and their loop IDs do not match (in case some are null, we return null). I am looking through how llvm.loop is used in the optimizer and came across this https://reviews.llvm.org/D26495 . we set the loop id to the newly created backedge in loopsimplify even some latches do not or have distinct loop ID's. These 2 things seem conflicting to me, i.e. on one side, we find and use the loop ID only if all the latches have them and they are identical, on the other side, we set loop ID (potentially use later) to the newly created backedge even though some latches do not have a loop id or have different loop IDs.

So which one is right ? Given a loop with multiple latches, and they have different loop IDs, can we use the loop ID and which one we use ?

sanjoy resigned from this revision.Jan 29 2022, 5:35 PM