This adds some safety checks into isInductionPHI so that users calling isInductionPHI do not need to do their own checks before calling the function.
Details
Diff Detail
Event Timeline
I'm not quite sure how to test this. I could test it through my use case in rewriteLoopExitValues for which I have tests already comitted (so it's more of an NFC). Or, it could be through some unit tests for isInductionPHI itself, I see tests in llvm/unittests/Analysis/IVDescriptorsTest.cpp. But these checks seem too trivial to add unit tests for. Is it okay to commit this without further testing?
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1546 | On the line below, we query for AR->getLoop()->getLoopPreheader(). If it turns out that this is null, we will see a crash. I thought adding this would be safer rather than restrictive. |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1546 | maybe Phi::getIncomingValueForBlock should return nullptr if passed nullptr? |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1521 | Sounds like a good case for Phi being a & (and additional const) rather than a non-const ptr. |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1546 | It would be possible to relax this to getLoopPredecessor(). Without a loop predecessor we would have to guard against multiple starting values, which is probably not worthwhile? |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1546 |
Oh yes, this also seems overly restrictive :/ The main thing we need an IR value to use as start value. Given that we already require a single latch, checking that all non-latch incoming values are the same should be fairly straight-forward :) Or maybe it is fine to pick any one of the non-latch incoming values as start value. We require the phi to form an AddRec, so it should have a single start value. Even if the incoming values are different IR values, they should evaluate to the same concrete value. |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1546 | Ok, I can try picking any of the non-latch incoming values and test that out. Another option is what isFPInductionPHI does: // The loop may have multiple entrances or multiple exits; we can analyze // this phi if it has a unique entry value and a unique backedge value. if (Phi->getNumIncomingValues() != 2) return false; Value *BEValue = nullptr, *StartValue = nullptr; if (TheLoop->contains(Phi->getIncomingBlock(0))) { BEValue = Phi->getIncomingValue(0); StartValue = Phi->getIncomingValue(1); } else { assert(TheLoop->contains(Phi->getIncomingBlock(1)) && "Unexpected Phi node in the loop"); BEValue = Phi->getIncomingValue(1); StartValue = Phi->getIncomingValue(0); } |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1546 | That seems like a good first step. IMO it would also make sense for them both to share the same logic to get the start value. |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1521 | No. Many APIs don't support null pointer arguments. The existing implementation of isInductionPHI requires this invariance and this patch should not regress it. |
This should never be called with Phi being null.