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

[Doerr, Martin]

Hi Roland,

I was hoping this was easier. I'd really appreciate to have more simple and comprehensive graph patterns. I wonder how many people will be able to debug them.

Given the huge amount of problems related to LSM I wonder if it's worth maintaining it. It comes with a high price.

Nevertheless, your version looks at least correct to me.

loopnode.cpp:
Please add your formula to the comment.

TestStripMinedLimitBelowInit.java:
I suggest to use -XX:-TieredCompilation

Best regards,
Martin


> -----Original Message-----
> From: Roland Westrelin <rwestrel at redhat.com>
> Sent: Montag, 4. Mai 2020 09:29
> 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,
> 
> > my idea was rather to check if the trip counter is already checked before
> the loop.
> > Check before loop should look like this (stride > 0 example):
> > CmpINode c = CountedLoop->in(1) -> IfTrue->in(0) -> If->in(1) -> Bool-
> >in(1) -> CompI
> >
> > (Maybe there's an easier way to find it where it gets generated.)
> >
> > Comparison of start value:
> > c->in(1) == Phi(trip counter)->in(1)
> > with limit:
> > c->in(2) == CmpI(trip counter)->in(2)
> >
> > If this matches we should be safe.
> > I haven't checked if such patterns match often enough. Just as an idea.
> 
> The code snippet I included does that but in a slightly different way
> (it looks for the CmpI/Bool with the right inputs and checks that it
> dominates the loops). That works for simple loops but I found it doesn't
> for other common loop shapes. So I doubt it's a as simple as it seems to
> follow your suggestion.
> 
> Roland.