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

[Tom Rodriguez]

Looks good.

tom

On May 5, 2011, at 5:30 PM, Vladimir Kozlov wrote:

> 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.