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

[Doerr, Martin]

Hi Roland,

I also prefer having the same solution for int and long.

"I'm not a fan of the complicated formula" means I could live with it, but it doesn't look like it's going to be my preferred solution.
The code is already hard to read and this makes it worse.

Maybe another option would be to recognize loops which are affected by this problem and live with having a safepoint in the body (skip LSM).
AFAICS "for" loops have the check at the beginning and should not be affected.

Best regards,
Martin


> -----Original Message-----
> From: Roland Westrelin <rwestrel at redhat.com>
> Sent: Donnerstag, 30. April 2020 10:18
> To: Doerr, Martin <martin.doerr at sap.com>; Pengfei Li
> <Pengfei.Li at arm.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 Martin,
> 
> Thanks for looking at this.
> 
> > Anyway, I'm not a fan of the complicated formula, either.
> 
> Another possibility would be to cast int values to long, compute the
> number of iterations and cast the result back to int. No need to worry
> about overflow then. I didn't go that way because 8223051 (support loops
> with long (64b) trip count) that I just sent out for review needs
> similar logic and there, promoting long values to 128 bit integers is
> not possible. I would like the logic of 8223051 and loop strip mining to
> remain as similar as possible.
> 
> Roland.