Intermediate writes to array slot not eliminated by optimizer

[Vitaly Davidovich]

Great, thank you

On Wed, May 13, 2015 at 10:19 AM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:

> > Thanks Roland.  Did you by chance confirm this on your end? I wanted to
> make sure this wasn't some artifact on my part.
>
> Yes, it’s a problem on our side.
>
> Roland.
>
> >
> > Vitaly
> >
> > On Wed, May 13, 2015 at 10:08 AM, Roland Westrelin <
> roland.westrelin at oracle.com> wrote:
> > Vitaly,
> >
> > I filed:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8080289
> >
> > Roland.
> >
> >
> > > On May 12, 2015, at 7:56 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > >
> > > Well, this seems more about detecting that each iteration of the loop
> is storing to the same address, which means if the loop is counted (or
> otherwise determined to end), then only final value can be stored.  Even if
> loop is not removed entirely and the final value computed statically (as
> one could conceive in this case), I'd think working with a temp inside the
> loop and then storing the temp value into memory would be good as well.
> > >
> > > FWIW, gcc and llvm do the "right" thing here in similarly shaped C++
> code :).
> > >
> > > On Tue, May 12, 2015 at 1:47 PM, Vladimir Kozlov <
> vladimir.kozlov at oracle.com> wrote:
> > > The most important thing we need do with this code is move Store from
> the loop. We definitely collapse empty loops.
> > > We do move some loop invariant nodes from loops but this case could be
> different. I think the problem is stored value is loop variant.
> > > Yes, it would benefit in general if we could move such stores from
> loops.
> > >
> > > Vladimir
> > >
> > > On 5/12/15 10:16 AM, Vitaly Davidovich wrote:
> > > Thanks Vladimir.  I believe I did see the split pre/main/post loop form
> > > in the compiled code; I tried it with both increment and decrement, and
> > > also a plain counted for loop, but same asm in the end.  Clearly the
> > > example I gave is just for illustrating the point, but perhaps this
> type
> > > of code can be left behind after some other optimization passes
> > > complete.  Do you think it's worth handling these types of things?
> > >
> > > On Tue, May 12, 2015 at 1:12 PM, Vladimir Kozlov
> > > <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
> wrote:
> > >
> > >     I would need to look on ideal graph to find what is going on.
> > >     My guess is that the problem is Store node has control edge
> pointing
> > >     to loop head so we can't move it from loop. Or stupid staff like we
> > >     only do it for index increment and not for decrement (which I
> doubt).
> > >
> > >     Most possible scenario is we convert this loop to canonical Counted
> > >     and split it (creating 3 loops: pre, main, post) before we had a
> > >     chance to collapse it.
> > >
> > >     Regards,
> > >     Vladimir
> > >
> > >     On 5/12/15 10:05 AM, Vitaly Davidovich wrote:
> > >
> > >         Anyone? :)
> > >
> > >         Thanks
> > >
> > >         On Mon, May 11, 2015 at 8:25 PM, Vitaly Davidovich
> > >         <vitalyd at gmail.com <mailto:vitalyd at gmail.com>
> > >         <mailto:vitalyd at gmail.com <mailto:vitalyd at gmail.com>>> wrote:
> > >
> > >              Hi guys,
> > >
> > >              Suppose we have the following code:
> > >
> > >              private static final long[] ARR = new long[10];
> > >              private static final int ITERATIONS = 500 * 1000 * 1000;
> > >
> > >
> > >              static void loop() {
> > >                   int i = ITERATIONS;
> > >                   while(--i >= 0) {
> > >                        ARR[4] = i;
> > >                    }
> > >              }
> > >
> > >              My expectation would be that loop() effectively compiles
> to:
> > >              ARR[4] = 0;
> > >              ret;
> > >
> > >              However, an actual loop is compiled.  This example is a
> > >         reduction of
> > >              a slightly more involved case that I had in mind, but I'm
> > >         curious if
> > >              I'm missing something here.
> > >
> > >              I tested this with 8u40 and tiered compilation disabled,
> > >         for what
> > >              it's worth.
> > >
> > >              Thanks
> > >
> > >
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150513/e0368f71/attachment-0001.html>