Page MenuHomePhabricator

[BasicAA] Don't assume a PHI node has inputs
Needs ReviewPublic

Authored by craig.topper on Apr 20 2018, 4:44 PM.



aliasPHI assumes that a phi node must have at least one input. Our internal code base with some jumpthreading changes was able to get into this code with a phi with no inputs in some unreachable code.

It seems robust to not have this assumption.

I don't have a test case that works on trunk.

Diff Detail

Event Timeline

craig.topper created this revision.Apr 20 2018, 4:44 PM

We have a verifier check that PHI nodes have at least one incoming value, so this should be impossible even in unreachable code.

Sorry I meant it became unreachable during jump threading. And jump threading itself created the degenerate phi. The call into alias analysis also came from jump threading from SimplifyPartiallyRedundantLoad.

But we do have our own internal changes in jump threading so its still possible that this is a problem there.

I found other code that handles phis with no incoming values in the phi handling in computeKnownBitsFromOperator. That code is exercised by 3 lit tests, 2 of them due to jump threading.

Trying to handle the invalid code we allow in unreachable blocks had so far
been a generally losing proposition. AFAIK we've always eventually given up
before getting any pass actually bug free. Can we just stop asking aa
about this?