getting newVariables in HSAILLIRGenerator

Doug Simon doug.simon at oracle.com
Fri Dec 6 00:25:36 PST 2013


Your use of the annotations for DeoptimizeOp look correct to me. What’s makes you say that $s0 really is live at the deopt in your example? Unless the deopt takes the ClassCastException value as an input (which does not appear to be the case), then it’s dead at the deopt (deopts are control flow sinks).

If you’re still having problems, please send me the c1visualizer log for the compilation of this method (i.e. -G:Dump= -G:MethodFilter=<qualified name of method>). You’ll know what *.cfg file to send based on console output like this:

CFGPrinter: Dumping method HotSpotMethod<String.hashCode()> to compilations-1386318229050_2.cfg

-Doug

On Dec 5, 2013, at 10:38 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> We were playing around with hsail handling for a deoptimization node.
> As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have
> 
>    @Override
>    public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) {
>        Variable scratch64 = newVariable(Kind.Object); 
>        Variable scratch32 = newVariable(Kind.Int); 
>        append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32));
>    }
> 
> and inside our HSAIL DeooptimizeOp we have
> 
>        @Use({REG, CONST}) protected Value actionAndReason;
>        protected DeoptimizingNode deopting;
>        protected MetaAccessProvider metaAccessProvider;
>        @Temp({REG}) private AllocatableValue scratch64;
>        @Temp({REG}) private AllocatableValue scratch32;
> 
> However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live.  For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block.
> 
> 
> @L12:
> 	mov_b32 $s0, -35;	// ClassCastException
> 	brn @L14;
> 
> @L14:
> 	// Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i
>       ... deoptimize codegen follows
> 
> -- Tom
> 
> 



More information about the graal-dev mailing list