RFR(S): 8244086: Following 8241492, strip mined loop may run extra iterations

[Doerr, Martin]

Hi Pengfei,

I had similar thoughts. However, seems like a "limit >= init" check before the outer loop would require cloning the loop body or inserting an uncommon trap in the example of the tests which use a do-while loop which runs exactly one iteration.

Anyway, I'm not a fan of the complicated formula, either.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Pengfei Li
> Sent: Donnerstag, 30. April 2020 04:43
> To: Roland Westrelin <rwestrel at redhat.com>; hotspot-compiler-
> dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: RE: RFR(S): 8244086: Following 8241492, strip mined loop may run
> extra iterations
> 
> Hi Roland,
> 
> I'm studying the strip mining code recently.
> 
> > With 8241492, I changed that computation to use an unsigned comparison
> > because limit - init can be greater that max_jint. This assumes that limit is
> > always greater that init but in some rare cases that doesn't hold. The body
> > should then be executed for only one iteration but the computation of the
> > number of iterations above causes it to run for LoopStripMiningIter. The fix
> I
> > propose is to change the computation to:
> >
> > min_unsigned(LoopStripMiningIter, max(0, limit - iv)) for stride > 0
> > min_unsigned(LoopStripMiningIter, max(0, iv - limit)) for stride < 0
> 
> Just one question: If the case that "limit < init" is quite rare (perhaps occurs
> only with some "synchronized (new Object()) {}" hack), is it better to add a
> "limit >= init" prediction and put it before the outer loop? I see the limit
> check for counted loops does in this way to avoid the overflow beyond
> max_jint.
> 
> --
> Thanks,
> Pengfei