Intermediate writes to array slot not eliminated by optimizer

[Roland Westrelin]

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
> 
> 
> 
>