HSAIL Backend: Register getting overwritten as part of Move To Phi

[Deneau, Tom]

The problem described below was first noticed last week but then I thought
it went away with the large number of checkins on July 15.  But now I see
that it is still there.

I am not sure how to debug this problem so looking for any suggestions.
To help you reproduce the problem on your side, I have a small webrev that
adds the failing test case.   The test case itself uses String.contains and so
needed the capability to properly handle accesses to char arrays and char fields,
so in addition to the failing test case there is a very small change to the HSAIL
backend to support the narrower object types like char.

The webrev can be found at
http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/

One other change in this webrev, I made a change to the okra library loading code
originally suggested by Doug.  Doug was suggesting a new environment variable pointing
to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
line.  Instead I noticed that we were already requiring the directory to be in the PATH
environment variable, so the loading code just looks down the PATH.

In the webrev, this change is simply reflected in a change to the version
of the okra jar file (since the okra code is not part of graal proper).
The change is entirely in the java code, there is no need
to rebuild the actual native libraries.

Reproducing the failing test case...

With the patch applied, you should be able to get the test case failure with the following:

   * mx --vm server build product
   * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest

The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
code starts at @L10.  We are reading the first char from each of the strings and
getting ready to compare them.

@L10:
	ld_global_u16 $s9, [$d0 + 24];
	ld_global_u16 $s10, [$d3 + 24];
	st_spill_s32 $s10, [%spillseg][24];
	mov_b32 $s9, 0;                          <<< problem       
	cmp_ne_b1_s32 $c0, $s9, $s10;


-- Tom Deneau



-----Original Message-----
From: Deneau, Tom 
Sent: Monday, July 15, 2013 4:05 PM
To: graal-dev at openjdk.java.net
Subject: RE: graal/graal: 107 new changesets

Doug or others --

I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
is just being hidden by some unrelated change.   Anyway, here is a brief description,
maybe you can tell which of the many changesets below would have fixed this, if any.

We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
HSAIL code which led to the problem

	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
	st_spill_s32 $s9, [%spillseg][24];     // register spill
	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered


When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
 "mov_b32 $s8, 0"
was generated as part of something called
       MOVE TO PHI from 276|EndNode to 277|LoopBegin

as part of PhiResolver.dispose, the part that is commented with
  // generate move for move from non variable to arbitrary destination

Does the above sound like something that was purposely fixed?

-- Tom Deneau