webrev for Graal HSAIL backend

[Deneau, Tom]

Morris --

Regarding your comments on the hotspot changes in this webrev
http://cr.openjdk.java.net/~ecaspole/graal_hsail/ 
I wanted to let you know that these hotspot changes really don't make
sense on their own but co-operate with some JDK changes which we will
be submitting in a separate webrev to the Sumatra-dev repository early
next week (these JDK changes are much smaller than the graal changes).

Here is a brief overview of how the pieces fit together...

Basically we wanted the GPU offload programming model to be triggered
by the programmer using Stream.parallel.forEach(). So the JDK changes
are really just interceptions of the stream API for parallel forEach.
The intercept code tests whether the stream meets a few criteria to be
offloadable, and if so tell graal (thru the Sumatra interface) to
compile the lambda method to HSAIL and dispatch it.  If already
compiled, it will just be dispatched.  Currently we have a property,
off by default, which tells the JDK intercept code to offload
immediately.  If the offload-immediate flag is set, no hotspot changes
are really needed.

The hotspot changes just provide an alternate way of enabling the
offloading (without using the offload-immediate flag) by using the
compilation of the underlying lambda method as a trigger for
offloading.  They are very experimental and we would welcome community
input on other ways to do this.

Hope this helps...

-- Tom Deneau



-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer
Sent: Tuesday, June 11, 2013 7:17 PM
To: graal-dev at openjdk.java.net
Subject: Re: webrev for Graal HSAIL backend

Vasanth,

After seeing Apple's WWDC and the 4,000 core dual-GPU system they built 
into the Mac Pro, I'm very happy to see the work your team has put 
together.  Lots of good stuff here and I think we should take most of it.

I like that the HSAIL backend is in the com.oracle.graal namespace - not 
so much as an Oracle engineer - but it will make working and refactoring 
these GPU and CPU backends much easier.  Thanks.

compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem 
like the might be a little specialized for this point in time.   Very 
interesting changes though.   I would like to get the heterogeneous 
method support into HotSpot / Graal and sit down at the language summit 
and discuss how we take on constructs like the ForEach work.

I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it 
echos the change I made to CompilerToGPU in the earlier PTX work.  I 
would like of like to reserve the sumatra package for lambda work along 
the lines you are thinking for a collections / lambda oriented 
java.lang.invoke set of code.   We need to get the requirements for this 
sort of externalized kernel creating defined as soon as we can.  Maybe 
...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages in the 
graal namespace?

I think it might be a good next step to put in the HSAIL back end and 
tests and the emulator working at the gate so we can build and verify 
JDK9 / Sumatra / Graal changes in this environment going forward.

I will be working as time permits on the heterogeneous methods and PTX 
invocation so we can get both platforms at the gate integrating changes.

That's all for now.  I'm looking forward to working my way through all 
these unit tests.  Huge kudos AMD!

         --morris meyer

On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote:
> Hi,
>
> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody.
>
> Features
>
> Arithmetic operations for integers, longs, doubles, and floats
> Loads, stores and move operations
> Min/max/rem/carry operations for integers and longs
> Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles).
> Some math library operations (e.g., square root).
> Support for JDK8 lambda constructs.
>
> Known Issues
>
> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work.
> -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention
> -Function call support has yet to be implemented.
>
> For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java
>
> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code.
>
> We encourage the community to support this new backend and extend it with additional features.
>
> Vasanth
>
>
>
>
>
>
>
>
>