Request for reviews (S): 7042327: assert(opaq->outcnt() == 1 && opaq->in(1) == limit)
tom.rodriguez at oracle.com
Thu May 5 17:01:00 PDT 2011
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?
On May 5, 2011, at 4:03 PM, Vladimir Kozlov wrote:
> 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.
More information about the hotspot-compiler-dev