question about bci in LIRFrameState for DeoptimizeOp

[Gilles Duboscq]

Since guards are scheduled early, in your example i would guess they are
indeed before the side effect.
You can have a look at this paper:
http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf it contains
information about how we handle deoptimization in Graal and about how we
use it for exceptional control-flow (which is probably also of interest in
the HSAIL runtime context).

Why are you looking at the deoptimization exactly? Do you have an idea
already about how you would handle them in HSAIL runtime?

-Gilles


On Wed, Nov 20, 2013 at 10:15 PM, Thomas Wuerthinger <
thomas.wuerthinger at oracle.com> wrote:

> I think the guards for the array access might have been moved before the
> field store. Can you check in the machine code whether the deoptimization
> is indeed *after* the field store? - thomas
>
> On 20 Nov 2013, at 22:08, Deneau, Tom <tom.deneau at amd.com> wrote:
>
> > Thomas --
> >
> > I retried this experiment with a java snippet that I thought would have
> a side effect, incrementing a field
> >    public int intFromArrayLonger(int[] ary, int idx) {
> >        dummyField++;
> >        return ary[idx];
> >    }
> >
> > But I still saw a info.bci of 0.
> >
> > -- Tom D
> >
> >
> >
> > -----Original Message-----
> > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com]
> > Sent: Wednesday, November 20, 2013 2:40 PM
> > To: Deneau, Tom
> > Cc: graal-dev at openjdk.java.net
> > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp
> >
> > Graal understands that it can safely replay bytecodes without side
> effects. Therefore the target bci of a deoptimization will reflect the last
> side effecting instruction (or the beginning of the method if no such
> instruction exists). Gilles wrote a paper describing in more details how
> deoptimization works in Graal and we will publish it shortly as part of the
> Graal documentation. - thomas
> >
> > On 20 Nov 2013, at 21:17, Deneau, Tom <tom.deneau at amd.com> wrote:
> >
> >> I was looking at the AMD64DeoptimizeOp.emitCode routine which is
> >>       AMD64Call.directCall(tasm, masm,
> >> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false,
> >> info);
> >>
> >> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP,
> the bci always seems to be 0.
> >> Why is that?
> >>
> >> For example, compiling this small snippet thru AMD64 backend
> >>   public int intFromArray(int[] ary, int idx) {
> >>       return ary[idx];
> >>   }
> >>
> >> with bytecodes
> >> public int intFromArray(int[], int);
> >>   Code:
> >>      0: aload_1
> >>      1: iload_2
> >>      2: iaload
> >>      3: ireturn
> >>
> >> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at
> >>
> com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46)
> [bci: 0]
> >>           |0  |1     |2
> >>  locals:  |-  |v0|a  |v1|i "
> >>
> >> I would have expected the bci in this case to be 2, referring to the
> iaload instruction.
> >>
> >> -- Tom
> >>
> >>
> >
> >
> >
>
>