Intermediate writes to array slot not eliminated by optimizer

[Vitaly Davidovich]

Thanks Roland.  Did you by chance confirm this on your end? I wanted to
make sure this wasn't some artifact on my part.

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/46edf70f/attachment.html>