patch for additional graal HSAIL backend functionality

[Deneau, Tom]

Doug --

Can you say a little more about what you meant by "Graal doesn't yet have proper support for multiple, configurable backends."

-- Tom

-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Monday, July 15, 2013 11:10 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: patch for additional graal HSAIL backend functionality


On Jul 15, 2013, at 2:38 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Yes, go ahead and make those fixes as part of your integration.
> With regards to the HSAILLIRGenerator, did you mean to say that the HSAILLIRGenerator should be in co.graal.compiler.hsail
> (like it is now) and there should be a new HSAILHotSpotLIRGenerator class in c.o.graal.hotspot.hsail?

Yes. However, I've realized that doing the proposed refactoring right now is a little premature given that Graal doesn't yet have proper support for multiple, configurable backends.

> For the original layout, I think Vasanth followed the way PTX was laid out

Ok, makes sense.

> Sorry for the eclipse errors I realize now I forgot to specify the JDT compiler on the mx command line.

You're not using Eclipse?! ;-)

-Doug

> $ find graal -print | grep LIRGenerator.java
> graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
> graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
> graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java
> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java
> graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java
> graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Monday, July 15, 2013 4:17 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: patch for additional graal HSAIL backend functionality
> 
> - this patch contains Eclipse errors (2) and warnings (13)
> - ForeignCallNoOp0 -> ForeignCallNoArgOp
> - ForeignCallNoOp1 -> ForeignCall1ArgOp
> 
> To save turn around time, I can simply make these fixes as part of my integration.
> 
> I also noticed for the first time that the c.o.graal.compiler.hsail project depends on c.o.graal.hotspot.amd64. The dependencies and structure for the HSAIL backend should more closely follow that for the AMD64 backend. The HSAILLIRGenerator class should be in the c.o.graal.lir.hsail project and there should be a HSAILHotSpotLIRGenerator subclass in a c.o.graal.hotspot.hsail project. Only the latter should introduce any HotSpot dependencies. I'm happy to make these refactoring if want.
> 
> -Doug
> 
> On Jul 13, 2013, at 1:26 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Please review the following webrev.  This webrev adds some new
>> features to the HSAIL backend, which are listed below:
>> 
>> -- Tom
>> 
>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/
>> 
>> 
>> * stackslot mapping was incorrect when combinations of 32-bit and
>> 64-bit stores were generated.  StackSlot alignment in
>> HSAILTargetDescription set to 8.
>> 
>> * compressedOops support in various heap size configurations (with or
>> without either of shift or heap base).  So we don't need
>> XX:-UseCompressedOops anymore.
>> 
>> * some support for unsigned shifts, long shifts, logical ops for long
>> datatype.
>> 
>> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>> able to handle HSAIL function calls yet, plus we are still working
>> on emitting HSAIL function calls in the compiler.
>> 
>> * hack for emitForeignCall special cases of createOutOfBoundsException
>> or createNullPointerException.  (We just emit a comment.  Real
>> exception handling still pending).  These nodes came about when we
>> more aggressively inlined, although this has not been explained yet.
>> 
>> * support HSAILAddressValues as operands for arithmetic ops.  Use
>> HSAIL lda instruction to get address into a register.  Used in
>> particular for USHR for card-marking.
>> 
>> * Added some new junit tests. (some ported from their lambda versions)
>> 
>>  * StaticNBodyCallTest which would fail with default inlining (since
>>    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>>    tests whether InlineEverything is set.  It (and also some
>>    lambda-based junit tests not part of this webrev) do pass nicely
>>    when InlineEverything is set true.
>> 
>>  * tests for storing an object, which test being able to handle the
>>    card-marking logic, as well as the encoding and decoding of a
>>    compressed oop.
>> 
>>  * some 2D matrix tests that showed a problem before the stackslot
>>    change above.  (have a mixture of 32-bit and 64-bit stackslot
>>    spills)
>> 
>> 
> 
> 
>