RFR: 8183137: [MVT] C2 doesn't eliminate redundant value type allocations inside loops

[Tobias Hartmann]

Hi Roland,

On 13.07.2017 17:54, Roland Westrelin wrote:
> Yes. Actually, I found after I posted the webrev that test95/test96
> don't behave as intended. I'll push a fixed version. Also, since I
> posted the webrev, I changed the condition cfgnode.cpp line 1636 to:
> 
> if (req() > 2 && in(1) != NULL && in(1)->is_ValueTypeBase() && (can_reshape || in(1)->is_ValueType())) {
> 
> It's only safe to apply that transformation once we know all inputs to
> the ValueTypePtr node.

Okay, makes sense.

> My plan for the non constant method handle case is to transform:
> 
> (Phi ValueTypePtr#1 Node#2) to (Phi ValueTypePtr#1 CheckCast#2)
> 
> with a CheckCast to the type of the ValueTypePtr then push the CheckCast
> through phi up until a call to a method handle linker. Modify the call
> so it now returns the type of the CheckCast instead of __Value, add
> projections to the call for all return values, allocate a new value type
> right after the call and populate it with the values from the
> projections, create a ValueTypePtr with the projection as field and the
> new allocation as oop edge. Then let the current machinery push it down
> through the Phis. I have it working on test95/test96.

Right, that's basically what Vladimir I. mentioned as well in another thread:

On 06.07.2017 13:52, Vladimir Ivanov wrote:
> There's one crucial simplifying assumption about __Value usages in LFs we can make: lambda forms don't merge VT pointers of different types. So, it's either merge of opaque value buffer pointers (PHI __Value* ... __Value* #__Value*) (when compiling stand-alone lambda forms) or merging concrete VTs of the same type (PHI VT1* ... VT1* #VT1*) (when inlining through method handle chains).

Very nice!

Best regards,
Tobias