RFR(XS): 8027626: assert(Opcode() != Op_If || outcnt() == 2) failed: bad if #1
vladimir.kozlov at oracle.com
Tue Jan 6 00:34:15 UTC 2015
Is it again the problem with IGVN list processing order?
What happens in a simple test case when only one branch is taking? How projection and If nodes are removed?
On 1/5/15 1:33 PM, Roland Westrelin wrote:
> Hi Vladimir,
> Thanks for looking at this.
>> I think correct fix will be eager dead 12212 If node elimination when 12214 is replaced by 18733. Keep it connected to graph can cause problems in other places.
> IfFalseNode::Identity() is what optimizes 12212/12214 out. Should I make it an Ideal transformation so that I can call igvn->remove_dead_node() on the dead branch?
>> On 1/5/15 7:48 AM, Roland Westrelin wrote:
>>> The following subgraph is where the bug shows up:
>>> If (18732)
>>> | \
>>> IfTrue IfFalse
>>> (18734) (18733)
>>> | |
>>> | If (12212)
>>> | | \
>>> | IfFalse IfTrue
>>> | (12214)
>>> | |
>>> Region (12183)
>>> Condition to 12212 is always false so 12214 is replaced by 18733 and both branches of If 18732 are directly connected to Region 12183. 18733 still has dead 12212 as output.
>>> 12183 doesn't have phis so when it's transformed, If 18732 is considered for removal. IfTrue 18734 doesn't have uses anymore so it goes away but IfFalse 18733 still has some (dead branch 12212 is not yet removed).
>>> An If in the dead branch 12212 is processed. Range check smearing follows dominator controls until 18733, tests whether the If is a range check and the assert fires because the If only has one projection.
>>> So we’re trying to optimize a dead branch. I fixed it by making the range check code more robust.
More information about the hotspot-compiler-dev