small webrev to enable some hsail virtual call inlining

[Deneau, Tom]

OK a second version of the webrev, the section in HSAILLIRGenerator.java mentioned below has been cleaned up as well as correcting some comments related to switches in HSAILControlFlow.java

http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining-v2/webrev/

-- Tom



From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Friday, May 16, 2014 11:54 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: small webrev to enable some hsail virtual call inlining


+        if ((key.getKind() == Kind.Int) || (key.getKind() == Kind.Long) || (key.getKind() == Kind.Object)) {
Maybe you should make this a switch now and the comment and exception message is not correct anymore:

             // Throw an exception if the keys aren't ints.

             throw GraalInternalError.unimplemented("Switch statements are only supported for keys of type int or long, not " + key.getKind());

On May 15, 2014, at 3:36 PM, Deneau, Tom <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:


I submitted a small webrev that enables some hsail virtual call inlining in a few junit tests...

http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining/webrev/

Changes

*         tests that want to inline multiple target calls need to have enough profile information so the graal Hsail backend knows which targets to inline.  Increased the kernel range to accomplish this.

*         The StrategySwitch implementation didn't handle switches of type Object.

*         The basic VirtualCallTest had two targets.  I added variations that had 3 and 4 targets.  These can only be run successfully with -XX:TypeProfileWidth being set to 3 or 4.  However they check TypeProfileWidth and just don't run if is not enough, so they do not fail under the default hotspot configuration (TypeProfileWidth = 2).

Note: I had hoped to enable passing of some other tests had virtual targets, for instance HashMapGetTest.  However HSAIL still requires complete inlining and the complete inlining of HashMap.Get fails because of maximum recursive depth being exceeded.  I believe this is on the TreeNode part of HashMap support, Treenode.find().  Maybe it is possible to do a substitution that does not use recursion.

I've noticed recursion hitting us in a few other places as well, some of which I would not expect for instance Float.toString()  which ends up trying to inline FDBigInteger.big5powRec

-- Tom