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
Unit Tests
Time | Test | |
---|---|---|
60,040 ms | x64 debian > libFuzzer.libFuzzer::value-profile-load.test |
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 | ||
---|---|---|
1542 | 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 | ||
---|---|---|
1542 | maybe Phi::getIncomingValueForBlock should return nullptr if passed nullptr? |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1517 | Sounds like a good case for Phi being a & (and additional const) rather than a non-const ptr. |
llvm/lib/Analysis/IVDescriptors.cpp | ||
---|---|---|
1542 | 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 | ||
---|---|---|
1542 |
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 | ||
---|---|---|
1542 | 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 | ||
---|---|---|
1542 | 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 | ||
---|---|---|
1517 | 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.