Suboptimal C2 code generation

[Vladimir Ivanov]

It looks like C2 stops halfway to desired shape.
The load is commoned, but repeated null check is not eliminated.

Final IR shape looks like:
   w = Load this._w

   If (w == NULL) deopt

   i = Load w._i

   If (i != NULL) {
     If (!i instanceof C) deopt
   } v1 = Phi(T:1,F:-1);

   If (i != NULL) {
     If (!i instanceof C) deopt
   } v2 = Phi(T:2,F:-1)

   return v1+v2

The next transformation would be:
   w = Load this._w
   If (w == NULL) deopt
   i = Load w._i
   If (i != NULL) {
     If (!i instanceof C) deopt
     If (!i instanceof C) deopt
   } v1 = Phi(T:1,F:-1)
     v2 = Phi(T:2,F:-1)
   return v1+v2

And finally:
   w = Load this._w
   If (w == NULL) deopt
   i = Load w._i
   If (i != NULL) {
     If (!i instanceof C) deopt
   } v1 = Phi(T:1,F:-1)
     v2 = Phi(T:2,F:-1)
   return i1+i2;

Best regards,
Vladimir Ivanov

On 11/20/15 5:29 AM, John Rose wrote:
> On Nov 19, 2015, at 2:58 PM, Vitaly Davidovich <vitalyd at gmail.com
> <mailto:vitalyd at gmail.com>> wrote:
>>
>>         return _w.value() + _w.value2();
>
> Which is (ignoring non-taken null branches):
>
>          return _w._i.value() + _w._i.value2();
>
> There are two independent fetches of _w._i in the bytecode.
> The machine code is treating them as independent, where
> we would want the optimizer to use a common value.
>
> The machine code is optimistic that _w._i is always a C,
> but it appears to be leaving open the possibility that some
> activity not tracked by the JIT could store some other C2 <: I.
>
> What happens at 0x00007ff5f82e00f9?  Does it de-opt,
> or does it merge back into 0x00007ff5f82e00b2?  In the
> latter case, the JIT cannot assume that _w._i is a C.
>
> So, it could be a failure to de-opt, or it could be some
> fluff in the IR which is preventing the two _w._i from
> commoning.  Or something else.
>
> — John