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

[Vladimir Ivanov]

Thanks, Razvan!

Best regards,
Vladimir Ivanov

On 2/13/18 1:01 AM, Lupusoru, Razvan A wrote:
> Hi Vladimir,
> 
> You have my +1 on this as well. I am very happy with how this work turned out - it definitely improved robustness of implementation.
> 
> --Razvan
> 
> -----Original Message-----
> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz
> Sent: Friday, February 09, 2018 4:24 PM
> To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Cc: panama-dev at openjdk.java.net
> Subject: Re: [vector] RFR (L): Vector box elimination improvements
> 
> 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.
> 
> Paul.
> 
>> 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
>