patch for additional graal HSAIL backend functionality
doug.simon at oracle.com
Tue Jul 16 12:10:54 PDT 2013
On Jul 16, 2013, at 8:58 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> Doug --
> Can you say a little more about what you meant by "Graal doesn't yet have proper support for multiple, configurable backends."
Currently, there is a single Backend instance available via the Graal.getRequiredCapability() API. Ideally, we want something more flexible for a system that has multiple backends (e.g., an AMD64 backend and a HSAIL backend). It maybe something like an extra API method like:
public static <T> T getRequiredCapability(Class<T> capability, Class<?>... extraCapabilities);
While returns an instance of the capability T that also implements some extra capabilities.
But there may be a better way - we don't want to do API design without some extra thought.
> -----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?! ;-)
>> $ find graal -print | grep LIRGenerator.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.
>> 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
>>> * 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
>>> * 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
More information about the graal-dev