assertion failure in NodeIntrinsification phase

[Christian Thalinger]

On Aug 14, 2013, at 1:06 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> Hi,
> 
> I've overriden Backend.newFrameMap() in HSAILBackend to return the HSAILRegisterConfig (instead of using the x86 register config) when the target is HSAIL.
> 
> I have a test case where the kernel calls a method foo( ) which calls another rmethod bar( ). When inlining is disabled with -X:-Inline, it works fine. However, when I don't include this flag, I was getting the following assertion error:
> 
> com.oracle.graal.graph.GraalInternalError: java.lang.AssertionError
> 	at node: 171|ReadRegister%r15
> Caused by: java.lang.AssertionError
> 	at com.oracle.graal.compiler.gen.LIRGenerator.setResult(LIRGenerator.java:177)
> 	at com.oracle.graal.replacements.nodes.ReadRegisterNode.generate(ReadRegisterNode.java:84)
> 	at com.oracle.graal.compiler.hsail.HSAILLIRGenerator.emitNode(HSAILLIRGenerator.java:105)
> 
> The assertion failure is coming from the below  code in LIRGenerator:
> 
> public Value setResult(ValueNode x, Value operand) {
>        assert (!isRegister(operand) || !attributes(asRegister(operand)).isAllocatable());
> 
> where the "operand" argument is getting passed the x86  RegisterValue of r15. The attributes( ).isAllocatable( ) call looks up the HSAILRegisterConfig to see whether the 15th register is allocatable. Because it is allocatable, we get an assertion failure. 
> 
> I was able to get around this error by marking the register whose id is 15 in HSAILRegisterConfig as non-allocatable, similar to the way r15 is marked as non-allocatable in AMD64RegisterConfig. However, I don't fully understand the basis for this and am looking for a longer term solution. 
> 
> Single stepping through this code, I found out that Graal is trying to intrinsify a routine called "registerAsWord" which is external to my test case.. As part of this it generates a ReadRegisterNode, passing it the x86 register r15. It's when it tries to generate this node (via call to ReadRegisterNode.generate()) that it hits the above assertion.
> 
> Can someone who has a better understanding of this NodeIntrinsificationPhase explain what would be the proper workaround for this? 

ReadRegisterNode is for specific registers.  The node you are referring to probably comes from:

ReadRegisterNode thread = graph.add(new ReadRegisterNode(hsRuntime.threadRegister(), true, false));

r15 is reserved for the thread register on AMD64.  Logic like this is still tied to the host runtime.

-- Chris

> 
> Vasanth
> 
> -----Original Message-----
> From: Venkatachalam, Vasanth 
> Sent: Tuesday, August 06, 2013 10:37 AM
> To: 'Thomas Wuerthinger'
> Cc: graal-dev at openjdk.java.net; morris.meyer at oracle.com
> Subject: RE: decoupling the HSAIL backend from using x86 register numbers.
> 
> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
>