question about bci in LIRFrameState for DeoptimizeOp

[Thomas Wuerthinger]

Can you always restart a kernel or do your kernels have intermediate side effects that cannot be undone?

- thomas

On 20 Nov 2013, at 23:27, Deneau, Tom <tom.deneau at amd.com> wrote:

> Gilles --
>  
> Yes, the guards were scheduled early in this case, before the side effect.
> Will take a look at the paper, thanks.
>  
> We are still in an early mode of exploring what information gets passed to the VM, and in what ways HSAIL can make use of that if a kernel gets an exception in one or more workitems.
>  
> Eric Caspole may have more to add on this.
>  
> -- Tom
>  
>  
> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
> Sent: Wednesday, November 20, 2013 3:36 PM
> To: Thomas Wuerthinger
> Cc: Deneau, Tom; graal-dev at openjdk.java.net
> Subject: Re: question about bci in LIRFrameState for DeoptimizeOp
>  
> 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
> >>
> >>
> >
> >
> >
>