Re: java aliasing rules

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Tom Tromey wrote:

>Bryce> For Dan's test case, I can get optimal code simply by setting
>Bryce> DECL_NONADDRESSABLE_P on all Java FIELD_DECLS (see the patch
>Bryce> below), there's doesn't seem to be any need for
>Bryce> java_get_alias_set or changes to the generic alias code to get
>Bryce> this.
>
>That's a nice patch!
>

Unfortunately the code generated is not entirely correct for Java. The 
reason is nothing to do with aliasing but rather NullPointerExceptions.

  public  void f (first  ps1, second ps2)
  {
      ps1.f1++;
      ps2.f2++;
      ps1.f1++;
      ps2.f2++;
  }

t.f(first, second):
       lhz 9,10(4)      #  <variable>.f1
       lhz 11,6(5)      #  <variable>.f2
       addi 9,9,2
       addi 11,11,2
       sth 9,10(4)      #  <variable>.f1
       sth 11,6(5)      #  <variable>.f2
       blr


With this code, if "ps2" is null then the second load (lhz) will throw 
before the ps1.f1 is seen as incremented. The optimal, correct code for 
Java is really something like:

lhz r9, [ps1.f1]
addi r9,r9,1
sth r9, [ps1.f1]
lhz r11, [ps2.f2]
addi r9,r9,1
addi r11,r11,2
sth r9, [ps1.f1]
sth r11, [ps2.f2]
blr

The second increment of ps1.f1 should not be allowed to be 
moved/combined ahead of the first "ps2.f2++", because it can trap/throw. 
The last two lines however cannot trap (since the first two would have 
done so already), so they can be safely moved/combined with other 
instructions)

None the less, I'm tempted to check in (to mainline) the 
DECL_NONADDRESSABLE_P change anyway, along with a PR and test case for 
the nullpointer problem. This is really just exposing a problem 
elsewhere in the compiler, which quite likely happens anyway in other 
situations when the aliasing stuff doesn't prevent it. Its also highly 
unlikely that any real applications are going to care about this 
behaviour, and exposing the problem will make it easier to fix it. What 
do you guys think?

regards

Bryce.