Request for reviews (S): 7042327: assert(opaq->outcnt() == 1 && opaq->in(1) == limit)

[Vladimir Kozlov]

Thank you, Tom

Thinking about what you said and, yes, such situation could happen. To be safe I 
need always put Opaque2 for limit for unrolled loop. I updated webrev.

Thanks,
Vladimir

Tom Rodriguez wrote:
> It seems ok.  Can't this situation occur as a result of other optimizations?  If limit is behind by some expressions that later gets optimized away it seems like the same configuration could happen.  Or isn't that possible?
> 
> tom
> 
> On May 5, 2011, at 4:03 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/7042327/webrev
>>
>> Fixed 7042327: assert(opaq->outcnt() == 1 && opaq->in(1) == limit)
>>
>> New loop unrolling code calculate new_limit = limit-stride. If limit is
>> trip-counter (phi+stride) with the same stride from a previous loop then new_limit will be optimized to pre-incremented value: new_limit = phi.
>> reorg_offsets() optimization will create a separate Opaque2 node for each use of trip-counter (phi) and as result zero trip guard limit will be different from loop limit and it causes the assert to fail.
>>
>> Separate limit by Opaque2 node when calculating new limit for unroll if limit is an incremented variable from previous loop to avoid using pre-incremented value and reduce register pressure.
>> I also removed code which creates dead loops since limit is input to new_limit.
>>
>> Tested with failed case and CTW.
>