Request for reviews (S): 7042327: assert(opaq->outcnt() == 1 && opaq->in(1) == limit)
tom.rodriguez at oracle.com
Thu May 5 17:57:08 PDT 2011
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.
> 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?
>> 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