threadRegister handling when compiling for other ISAs

[Doug Simon]

Any call may throw an exception and so Graal models this as an exception edge from the call to an exception handler. The only deviation from this is if profiling information says that the call in question never threw an exception.

How the exception object is transmitted from a callee to the caller is runtime specific and hence LoadExceptionObjectNode.lower() defers to the runtime (i.e., a GraalCodeCacheProvider instance). This is the 'GraalCodeCacheProvider runtime' parameter passed to GraalCompiler.compileGraph(). So, in HSAILCompilationResult.getHSAILCompilationResult() you need to pass in a GraalCodeCacheProvider instance that models the HSAIL runtime. You probably want an object that mostly delegates to the host runtime (retrieved via Graal.getRequiredCapability(GraalCodeCacheProvider.class)) but intercepts for HSAIL specific behavior.

-Doug

On Aug 21, 2013, at 9:31 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> Hi,
> 
> I was debugging the HSAIL compilation for a  test case involving method calls where A()calls B() and B()calls C()
> 
> When I ran this with inlining enabled, I was initially getting an error:
> 
> com.oracle.graal.graph.GraalInternalError: java.lang.AssertionError
>     at node: 171|ReadRegister%r15
> coming from an assertion check which checks to see if r15 (which is reserved for the thread register) is allocatable.
> 
> I traced where this r15 value is coming from. Graal is calling a routine HotspotReplacementUtils.threadRegister( ) which is querying the host runtime (x86) to get the thread register r15.
> 
> 
> public static Register threadRegister() {
>        return graalRuntime().getRuntime().threadRegister();
>    }
> 
> 
> 1) It looks like the threadRegister( ) method should be querying the target ISA (which in this case is HSAIL) instead of the host runtime for the thread register.
> For HSAIL we haven't marked any register as being the "thread register". What we are eventually planning to do is to pass a reference to the object that represents the current thread (as a parameter to any routine that needs it) instead of storing a pointer to the thread in a fixed register.
> 
> However, we are looking for a reasonable way to get around this issue in the short term. Any suggestions?
> 
> II. Some additional questions:
> 
> What leads to the above call to threadRegister() is that we hit some code in HotspotRuntime.java which processes a LoadExceptionObjectNode:
> 
> else if (n instanceof LoadExceptionObjectNode) {
>            exceptionObjectSnippets.lower((LoadExceptionObjectNode) n);
> 
> As a result of this Graal initiates a NodeInstrinsificationPhase where it tries to intrinisfy various snippets or utility routines in HotspotReplacementsUtil.java. One of these is the threadRegister( ) routine:
> 
> 
> 1) Why is the LoadEXceptionObjectNode being created for a test case where a() calls b() and b() calls c()?
> 
> 2) Why is AMD64HotspotRuntime still loaded even when we're not generating code for x86? Is there a reason why it needs to be loaded even though x86 is not the ISA we are compiling for?
> 
> Vasanth
> 
>