Path-dependent type constraints? (Was: Re: A simple optimization proposal)

[Krystal Mok]

Hi John,

It seems like C2 doesn't aggressively add type constraints based on
control-flow. Instead, it depends on a lot of pattern matching on
dominating tests, e.g. IfNode::filtered_int_type().

Could you please share the history and reason of this? Is it because having
too many CastII nodes in the graph makes it harder to do pattern matching
in various places?

Thanks,
Kris

On Thu, Feb 13, 2014 at 12:32 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Feb 13, 2014, at 9:11 AM, Krystal Mok <rednaxelafx at gmail.com> wrote:
>
> Here, the code in line 1 should ensure a.length > 2, and that predicate
> should propagate to line 2. But in the generated code, there's still a
> bounds check (a.length != 0) in line 2, right before the actual element
> load.
>
>
> We use two main sources of information to delete redundant tests: type
> information (such as integer ranges) and pattern matching on dominating
> tests (IfNode::).  In this case, the array type information does not carry
> the path-dependent information about a.length.  And, the dominating checks
> are not sufficiently similar to fold together.  But the common case is
> optimized, so I'm happy.
>
> You might want to look at the code for HashMap.getNode, which (I think)
> optimizes with your existing logic.
>
> -- John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140214/5c71c642/attachment.html