[vector] RFR (L): Vector box elimination improvements

[Vladimir Ivanov]

Thanks, Paul!

> Java source changes look good.
> 
>    49     private $type$[] getElements() {
>    50         return VectorIntrinsics.maybeRebox(this).vec;
>    51     }
> 
> So this is here to track accesses to the vector internals? I was wondering if there was also another complementary approach to track the accesses to the elements if vectors registers are to be retained e.g. there is an intermix of intrinsic and non-intrinsic vector ops. If so we could implement all those accesses via method calls rather than array loads/stores to vec if that helps.

It's here to both track accesses & keep additional information (JVM 
state) for optimization purposes.

Indeed, I observed problems in box elimination with mixing intirnsified 
& non-intrinsified operations. Field accesses don't keep JVM state at IR 
level, so aggressive reboxing doesn't work there.

The complementary approach you described makes perfect sense to me.

Replacing vector box & array element accesses with a registerized vector 
value & extract/insert instructions should improve code quality both in 
non-intrinsified cases and mixed scenarios. That fits graceful 
performance degradation goal well.

It was implemented for super-longs and proved to be working well.

IMO both approaches have their merits.

Benefits of keeping vectors in registers are evident.

Regarding VI.maybeRebox(), until full-blown value type support is there, 
there should be some special treatment of vectors in C2 to eliminate 
boxes and there'll be some corner cases which aren't covered by the 
analysis.

I envision that exposing VI.maybeRebox() and as part of Vector API (for 
example, as Vector.identity()) may help in some cases to improve 
generated code. It'll require good understanding of internals to put the 
calls in proper places, but can be a good stop-the-gap solution for 
unwanted vector box retention.

Best regards,
Vladimir Ivanov

>> On Feb 9, 2018, at 2:17 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/panama/vector.box_elimination/webrev.03/
>>
>> Different improvements in vector box elimination to make it more robust:
>>
>>   * Moved VectorBox/VectorUnbox to compile.cpp from macro;
>>
>>   * Lazy vector box materialization (before EA, but after VB/VU elimination);
>>
>>   * Introduced VectorBoxAllocate to capture JVM state for allocation materialization purposes;
>>
>>   * Vector box rematerialization at safepoints (when used from debug info);
>>
>>   * Aggressive vector reboxing;
>>
>>   * Introduced VectorIntrinsics.maybeRebox() to help aggressive reboxing by capturing JVM state and keeping it during optimizations on VB/VU nodes;
>>
>> Optimization phase for vector operations looks as follows:
>> (1) Expand VectorUnboxNodes
>> (2) Scalarize VectorBoxNodes
>> (3) Inline VI.maybeRebox() calls
>>
>> (4) RemoveUseless + IGVN
>>
>> (5) Expand VectorBoxNodes/VectorBoxAllocateNodes
>> (6) Eliminate unused VectorBoxAllocateNodes
>>
>> (7) RemoveUseless + IGVN
>>
>>
>> TRANSFORMATIONS
>>
>> The following transformations (some details [1]) are the core of the optimization:
>>
>> (A) VB/VU elimination
>>        VectorUnbox (VectorBox box value)  =>  value
>>        LoadVector  (VectorBox box value)  =>  value
>>
>> (B) Merge-through-phi
>>        Phi (VectorBox o1 v1) (VectorBox o2 v2)
>>        =>
>>        VectorBox (Phi o1 o2) (Phi v1 v2)
>>
>> (C) Reboxing
>>        VectorBox (Phi o1 o2) (Phi v1 v2)
>>        =>
>>        VectorBox new_box (Phi v1 v2)
>>
>> (D) Expansion
>>        VectorBox   box value  => box
>>        VectorUnbox mem box    => LoadVector box
>>
>> (E) Rematerialization
>>        SafePoint … (VectorBox box value) … 

>>        =>
>>        
SafePoint … (SafePointScalarObject box_klass #value) … value
>>
>>
>> KNOWN ISSUES (will be fixed later):
>>
>>   (1) Elimination of unused vector boxes can produce loops w/o safepoints.
>>
>>   Can be fixed by replacing VBA nodes with a safepoint.
>>
>>   (2) No distinction between indentity-preserving and identity-changing transformations: both aggressive reboxing and rematerialization can lead to observable changes in identity of vector boxes at runtime.
>>
>>   The plan is to add a flag and explicitly enable identity-changing transformations. It's easy to detect when box identity is observable and avoid reboxing & rematerialization if the flag is turned off.
>>
>>
>> FUTURE IMPROVEMENTS / CLEANUPS
>>
>>   - No need for VB/VU/VBA to stay macro nodes.
>>
>>   - Convert all stores during box allocation (see Compile::expand_vbox_alloc_node) into initialization stores.
>>
>>   - Aggressive unboxing (using VectorUnbox nodes) to help merge-through-phi transformation.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] http://mail.openjdk.java.net/pipermail/panama-dev/2017-December/000840.html
>