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

[Tom Rodriguez]

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.