RFR(L): 8205044: [lworld] Interpreter and compiler support for acmp with value type operands

[Tobias Hartmann]

Hi John,

thanks for looking at this!

On 12.07.2018 09:35, John Rose wrote:
> I was liking it all the way to the last file, especially the
> part that went "speculate, speculate, speculate"–truly
> a sentiment for our times.  When I got to the last file,
> with CmpLNode::Ideal, I noticed that it seems to maybe
> work correctly for the particular graph shapes created
> elsewhere, but not considered in isolation.  Note that
> there is no reference to in(2), only in(1)->in([1 or 2]).
> It can't be correct, in general, to execute the non-null
> returns, if you didn't inspect in(2).  I think you need
> more pattern-matching here; it's too eager to get to
> the win as coded.

Right, that code relies on the fact that we currently don't have a CmpLNode with a
OrLNode(CastP2XNode, CastP2XNode) input ever. That code pattern is only generated by
Compile::optimize_acmp(). But I agree that we should strengthen the CmpLNode::Ideal() pattern
matching by looking at in(2) as well.

What about this?
http://cr.openjdk.java.net/~thartmann/8205044/webrev.02_inc/

I've already pushed (right before receiving your email) but will push this as a follow up fix.

> I reviewed it and approve (heartily) of all of it, except
> for the above misgiving.

Thank you!

Tobias