RFR: 8291600: [vectorapi] vector cast op check is not always needed for vector mask cast [v7]

Xiaohong Gong xgong at openjdk.org
Thu Sep 15 07:53:55 UTC 2022


On Thu, 15 Sep 2022 07:16:39 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge branch 'jdk:master' into JDK-8291600
>>  - Address review comments
>>  - Add vector cast op check for vector mask for some cases
>>  - Revert the unify changes to vector mask cast
>>  - Merge branch 'jdk:master' into JDK-8291600
>>  - Fix x86 codegen issue
>>  - Unify VectorMaskCast for all platforms
>>  - Merge branch 'master' into JDK-8291600
>>  - 8291600: [vectorapi] vector cast op check is not always needed for vector mask cast
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2554:
> 
>> 2552:       op = gvn().transform(new VectorReinterpretNode(op, src_type, resize_type));
>> 2553:       op = gvn().transform(VectorCastNode::make(cast_vopc, op, elem_bt_to, num_elem_to));
>> 2554:     } else { // num_elem_from == num_elem_to
> 
> There is one comment unrelated to this patch but since your patch touches this function may be we can address it.
> Call to VectorMaskCastNode::makeCastNode in else block at following line
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L2555
> should be able to handle the true block. 
> But, newly created IR node on following location https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectornode.cpp#L1761 should be passed through gvn transform before returning.

Yes, you are right. That's also what is the first version of this PR (please see: https://openjdk.github.io/cr/?repo=jdk&pr=9737&range=00).  And since @merykitty  suggested to unify the whole vector mask cast operations with `VectorMaskCastNode`, I prepare a follow-up patch to specifically do this refactorization (please see: https://github.com/openjdk/jdk/pull/10192). And as suggested by @DamonFool , we only fix the `FIRST_NONZERO` performance issue in this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9737


More information about the hotspot-compiler-dev mailing list