question about bci in LIRFrameState for DeoptimizeOp

[Deneau, Tom]

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<mailto: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<mailto: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<mailto:thomas.wuerthinger at oracle.com>]
> Sent: Wednesday, November 20, 2013 2:40 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net<mailto: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<mailto: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
>>
>>
>
>
>