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.