RFR(L): 8205044: [lworld] Interpreter and compiler support for acmp with value type operands
tobias.hartmann at oracle.com
Thu Jul 12 08:32:37 UTC 2018
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?
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.
More information about the valhalla-dev