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