LIRFrameStates

Gilles Duboscq duboscq at ssw.jku.at
Mon Jan 13 04:42:10 PST 2014


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

>
> On Dec 24, 2013, at 7:31 PM, Deneau, Tom <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
> >    }
> >
>
>


More information about the graal-dev mailing list