webrev for hsail backend merging with new providers infrastructure

[Deneau, Tom]

Hi Doug --

Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet.  If you want to remove them from the public mx/projects, go ahead.

This points to a hole in our testing strategy which we've always been aware of.  We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository.  We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work.

On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything  -G:-RemoveNeverExecutedCode.   We need InlineEverything because we don't support HSAIL function calls yet.  Several test cases have a line like
       assumeTrue(aggressiveInliningEnabled());

and of course these just get skipped if -G:+InlineEverything is not set.  Is it possible to get the hsail tests that get run at Oracle to use these two flags?

-- Tom


-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Monday, November 04, 2013 9:30 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: webrev for hsail backend merging with new providers infrastructure

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
> 
>