LIRFrameStates

[Deneau, Tom]

Gilles --

Yes, I have noticed the frame state being saved at merges, thanks for explaining the reason.

-- Tom



From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Monday, January 13, 2014 6:42 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net; Doug Simon
Subject: Re: LIRFrameStates

In addition to what Doug described, some frame state can appear around merges even if there is no side-effect. We need a frame state at merges in the case there is a side effect in one of the incoming branches. We currently conservatively keep frame states for all merges.

Some time ago we experimented with discarding them when there are no side effects in the merged branches. At the time other things where not quite ready.
I think we could have a look at that again now and at least make it an option that we could use when we want to take advantage of the bci=0 special case (such as for GPU kernels).

Also, this loop shouldn't require a safepoint. We should be able to insert a limit check/overflow guard and remove the safepoint.

-Gilles

On Wed, Dec 25, 2013 at 4:37 PM, Doug Simon <doug.simon at oracle.com<mailto:doug.simon at oracle.com>> wrote:

On Dec 24, 2013, at 7:31 PM, Deneau, Tom <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:

> In the compilation of our Mandelbrot method test case (java code shown below), I noticed that besides the LIRFrameState for bci=0, there was also one created
>   * the beginning of the while loop
>   * the beginning of the first statement after the while loop
>
> so an exception detected at the final statement would use the LIRFrameState for the beginning of the first statement after the while loop.
>
>> From my reading of the http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf paper, I would have thought that new LIRFrameStates are needed only when there is a bytecode with side effects, and I don't see any side effects until we get to the final java line.  So just curious why were the two other LIRFrameStates created?
The frame state at the beginning of the loop is for placing a safepoint in the loop. The second frame state is there to account for the fact that execution can restart before the array load instruction.

-Doug

> =============================
>    public static void run(int[] rgb, int[] pallette, float xoffset, float yoffset, float scale, int gid) {
>        final int width = initWidth;
>        final int height = initHeight;
>        float lx = (((gid % width * scale) - ((scale / 2) * width)) / width) + xoffset;
>        float ly = (((gid / width * scale) - ((scale / 2) * height)) / height) + yoffset;
>        int count = 0;
>        float zx = lx;
>        float zy = ly;
>        float newzx = 0f;
>
>        // Iterate until the algorithm converges or until maxIterations are reached.
>        while (count < maxIterations && zx * zx + zy * zy < 8) {
>            newzx = zx * zx - zy * zy + lx;
>            zy = 2 * zx * zy + ly;
>            zx = newzx;
>            count++;
>        }
>        rgb[gid + 1] = pallette[count];   // will cause exception on last of range
>    }
>