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

Krystal Mok rednaxelafx at gmail.com
Fri Feb 14 11:36:32 PST 2014

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

More information about the hotspot-compiler-dev mailing list