decoupling the HSAIL backend from using x86 register numbers.

[Venkatachalam, Vasanth]

Thanks for the responses. This all makes sense now. What I need to do is define HSAILRegisterConfig (which implements the RegisterConfig interface) and override Backend.newFrameMap() in HSAILBackend to return this register config instead of doing runtime.lookupRegisterConfig().

Vasanth

-----Original Message-----
From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] 
Sent: Monday, August 05, 2013 10:34 PM
To: Venkatachalam, Vasanth
Cc: graal-dev at openjdk.java.net; morris.meyer at oracle.com
Subject: Re: decoupling the HSAIL backend from using x86 register numbers.

Yes. The HotSpotGraalRuntime should be of the platform kind for which the HotSpot native code itself is compiled. The HSAILBackend should override the Backend.newFrameMap() method to provide a custom register configuration instead of calling runtime.lookupRegisterConfig().

- thomas

On Aug 5, 2013, at 4:12 PM, Morris Meyer <morris.meyer at oracle.com> wrote:

> Vasanth,
> 
> You might be running older code as there are no longer separate SPARCHotspotBackend and SPARCBackend classes.  Christian Thalinger fixed this a while ago.
> 
> One of the Graal folks might need to correct me, but it seems like you would only want one runtime instance as the externalized PTX and HSAIL kernels are launched off that instance rather than having their own unique HotSpot runtime class.
> 
> Graal is treating PTX and HSAIL as sort of co-processors - rather than having a HotSpotRuntime instance on the GPU.
> 
> In code that I have for PTX return value passing, we have to marshal arguments anyway to set up the external kernel.
> 
> Perhaps the better way to do this would be to augment HSAILBackend to ensure that it creates the TargetMethodAssembler for HSAIL with the proper register allocator.
> 
>        --mm
> 
> 
> 
> On 8/5/13, 3:23 PM, Venkatachalam, Vasanth wrote:
>> I realized there was one more step to this process  which I didn't mention below:
>> 
>> The makeInstance() method which creates a new runtime (either x86 or Sparc) gets invoked by C++ code from the graalRuntime() method in graalVMToCompiler.cpp
>> 
>> It looks like I would have to modify this method in graalVMToCompiler.cpp by adding an #ifdef for the case where the architecture is HSAIL, so that the runtime that gets instantiated (through the call to makeInstance) is HSAILHotspotGraalRuntime, which I would define in the com.oracle.graa.hotspot.hsail package.
>> 
>> As a result of this change, the Backend object will be passed an HSAILHotSpotGraalRuntime instead of an AMD64HotSpotGraalRuntime, so Backend.newFrameMap() should be able to pick up on the HSAIL register configuration (via the call to runtime.lookupRegisterConfig().
>> 
>> Let me know whether this sounds right.
>> 
>> -----Original Message-----
>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Venkatachalam, Vasanth
>> Sent: Monday, August 05, 2013 3:59 PM
>> To: graal-dev at openjdk.java.net
>> Subject: decoupling the HSAIL backend from using x86 register numbers.
>> 
>> Hi,
>> 
>> I'd like to make changes so that the register allocator picks up on the HSAIL register configuration when the intended target is HSAIL. As I understand it, the register allocator is platform agnostic but  makes calls to an API that is returning an x86 register configuration. As a result, the  HSAIL assembler is being passed x86 register numbers. Thomas Wuerthinger and I discussed how I could go about addressing this issue. I took a look at how the Sparc backend is handling this and came up with the following steps.
>> 
>> Let me know whether this is on the right track or if there's a more efficient way of doing this.
>> 
>> 
>> 1)      Define a package com.oracle.graal.hotspot.hsail.
>> 
>>  In that package,
>> 
>> 
>> 2)      Define HSAILHotSpotRegisterConfig which implements the RegisterConfig interface. This overrides various routines (in RegisterConfig) that are called by the register allocator (e.g., getAllocatedRegisters() etc).
>> 
>> 
>> 3)      Define HSAILHotspotRuntime (subclass of HotspotRuntime). This overrides the createRegisterConfig( ) method to create  anew HSAILHotspotRegisterConfig
>> 
>> 
>> 4)      Define HSAILHotSpotGraalRuntime (subclass of HotspotGraal Runtime). Tihis would define the methods createArchitecture(), createBackend(), createRuntime() which get invoked by HotspotGraalRuntime() so that the runtime engine can pick up on the HSAIL register config.
>> 
>> Some questions:
>> 
>> What is the difference between SparcHotspotBackend and SparcBackend? The code looks very similar. Do we need an HSAILHotspotBackend in addition to the existing HSAILBackend?
>> 
>> In com.oracle.graal.hotspot.sparc, it looks there are a number of  additional classes (SPARCDirectStaticCallOp, SPARCSafepointOp etc) that may not be needed immediately for what I'm trying to do. Can I hold off on defining the corresponding classes in com.oracle.graal.hotspot.hsail? If not, which of these would be required to get the basic functionality of  allowing the register allocator to pick up on the HSAIL register configuration?
>> 
>> Vasanth
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>