patch for additional graal HSAIL backend functionality

[Doug Simon]

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