Intermediate writes to array slot not eliminated by optimizer

[Vitaly Davidovich]

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
> 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>> 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/20150512/f909ca8e/attachment.html>