webrev for hsail backend merging with new providers infrastructure

[Doug Simon]

Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them.

-Doug

[1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html

On Nov 1, 2013, at 11:54 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> All --
> 
> I have posted a small webrev to
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/
> 
> This is the result of our merge with the recent providers infrastructure.  Could you please look this over?
> 
> Here is a brief summary:
> 
> 
> HSAILHotSpotForeignCallsProvider.java
> -------------------------------------
> . As noted in the comments,   we don't really support foreign calls yet,  yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them.  We just support them all and lazily create dummy linkages here.  When we finally support foreign calls we will explicitly register the ones we want to support. 
> 
> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java
> ----------------------------------------------------------------------------
> . This again is part of the dummy Foreign Call support.   Some less extensive ForeignCall support used to be in HSAILLIRGenerator.
> 
> HSAILHotSpotReplacementsImpl.java
> ---------------------------------
> . This is another one of the providers in the new runtime infrastructure.  For both macro substitutions and method substitutions, we just delegate to the host substitution list.  This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change.  Eventually, we will explicitly list which substitutions we will support.
> 
> HSAIL.java
> ----------
> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out.
> 
> Tests
> -----
> . With the ForeignCall support above, some test cases that were marked as failing are now passing.
> 
> KernelTester.java
> -----------------
> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases.
> 
> 
> -- Tom Deneau
> 
>