Graal final field treatment with respect to optimizations

[Vitaly Davidovich]

That's good to know, but I would be quite upset if "new int[2].length == 2"
didn't fold :) In the cases I'm thinking of, the allocations aren't part of
the inlining horizon; in fact, the allocated objects live for a long time,
possibly eternal, but they're not constants to the compiler.

On Mon, Apr 27, 2015 at 5:57 PM, John Rose <john.r.rose at oracle.com> wrote:

> 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