Suboptimal C2 code generation

[John Rose]

On Nov 19, 2015, at 2:58 PM, Vitaly Davidovich <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151119/5775a746/attachment.html>