small webrev to enable some hsail virtual call inlining

Deneau, Tom tom.deneau at amd.com
Thu May 15 22:36:05 UTC 2014


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



More information about the graal-dev mailing list