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

[John Rose]

On Jul 13, 2018, at 7:34 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi John,
> 
> I've now remembered why I had to create a new node instead of returning a constant in my original
> patch. The problem is that we cannot return a (potentially cached) constant from Ideal because
> "Idealize should return new nodes, use Identity to return old nodes".
> 
> To keep things simple and to avoid code duplication, I've factored the acmp optimizations into
> Compile::optimize_acmp which is both used during parsing and during Ideal. We could move the paths
> that return constant false into ::Value or ::sub but that would require to duplicate the pattern
> matching code and could also not be used during parsing.
> 
> I think the best we can do without increasing complexity is this:
> http://cr.openjdk.java.net/~thartmann/8205044/webrev.03_inc/
> 
> I've added comments explaining why we cannot return a constant. In general, those CmpNodes with
> constant input will be immediately folded to constant false by GVN, so although it's a bit hacky,
> there is no impact on code generation.

That's better, but I'll do you one more:

- Ideal must return a new node.
- Identity may return an old node.
- Value may return a *constant* by returning a midline type.

(I don't think the distinction between Ideal and Identity is very interesting
or useful, BTW.)

I think your methods that potentially return a constant result should
be moved from Ideal to Value.

— John