Graal final field treatment with respect to optimizations

John Rose john.r.rose at oracle.com
Mon Apr 27 21:57:06 UTC 2015


On Apr 27, 2015, at 1:29 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> There's a range check on each one even though it's "obvious" there shouldn't be one.  I'm sure we could come up with more examples, but the common pattern is there's no dominator to use.

Subset types flow from dominating definitions as well as tests.

With enough inlining, the use site can "see" the allocation site, including specific parameters of the allocation, and that's as good as a dominating check for folding up subsequent checks.

As an extremely local example, this code becomes a no-op:

    assert(new int[2].length == 2);

The dominating check you are thinking of corresponds to:

    assert(aa.length == 2 && aa.length == 2);

You can probably see that, after inlining, large amounts of code can appear between the allocation site and the checks, but (under generous conditions) the same optimizations apply as in the above trivial cases.

— John


More information about the graal-dev mailing list