Request for reviews (S): 7042327: assert(opaq->outcnt() == 1 && opaq->in(1) == limit)
vladimir.kozlov at oracle.com
Thu May 5 17:30:12 PDT 2011
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