question about calling convention changes

Bharadwaj Yadavalli bharadwaj.yadavalli at oracle.com
Mon Sep 9 12:37:45 PDT 2013


Hi Vasanth,

On 9/9/2013 12:27 PM, Venkatachalam, Vasanth wrote:
>
> I'm looking for some guidance on changes I'm implementing to get my 
> HSAIL backend to use a  calling convention that's more aligned with 
> the convention that HSAIL uses.
>

I have not seen the HSAIL backend implementation. I am assuming that you 
have defined a AMD64HotSpotGraalRuntime, CallingConvention and register 
configuration etc to represent HSAIL.

<...>

The issues you appear to be addressing during HSAIL codegen seem similar 
to those that we've been working on for PTX codegen - although, at 
present, we only emit code for PTX _kernel_ entry prologue (we do not 
generate PTX _functions_ yet but would expect the basic technique to be 
similar).

> As expected, Graal is creating MoveToRegOp nodes in emitPrologue( ) 
> for each for the function params with the above Boolean param set to 
> true.
>
> However, it isn't generating the proper code for the very last param. 
>  What I find is that for the last param, emitCode( ) is calling 
> HSAILMove.move( ) with the isPrologue  parameter set to false.
>
> Debugging this issue I found that somewhere down the road, Graal is 
> inserting a moveToReg node (which by default has the isPrologue field 
> set to false) in the cnain of calls MoveResolver.insert( ) -> 
> spillMoveFactory.createMove( ). I suspect this extraneously added 
> movetoRegOp may be the culprit, but I'm not sure how to work around 
> this. Any suggestions?
>

Not sure where that additional moveToReOp is coming from but one place 
that I encountered such situation is visitReturn() and have an 
overridden PTXLIRGenerator::visitReturn() to handle this.

> Also,
>
> 1)Is my overall approach correct for what I'm trying to do?
>

I think overriding emitPrologue() to provide the appropriate 
implementation for HSAIL architecture is the right way to handle the issue.

> 2)In the case of a kernel function, the last parameter has to be 
> treated specially. Instead of generating a load for it as above, we 
> need to generate a workitemabsid instruction. Do people have 
> suggestions on where I can add some logic to intercept the last 
> parameter and treat it special when emitting code for the prologue?
>

You may find it informative to look at 
PTXILIRGenerator()::emitPrologue() and PTXLIRGenerator::visitReturn().

Hope that helps.

Bharadwaj



More information about the graal-dev mailing list