decoupling the HSAIL backend from using x86 register numbers.

[Venkatachalam, Vasanth]

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