[vectorIntrinsics] RFR: 8283413: Add C2 mid-end and x86 back-end implementation for bit REVERSE and REVERSE_BYTES operation [v6]

[Jatin Bhateja]

On Fri, 8 Apr 2022 01:51:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks @theRealELiu ,  its handled on the lines of Revers transformation during final graph reshaping.
>
> FTR, Reverse[bytes] related transforms are special since they cannot be done locally in associated Identity routines since corresponding IR  nodes may be succeeded by blends which are generated after creation of Reverse[bytes] IR, thus GVN related routines for both blend and Reverse[bytes] IR may not be able to handle this transform,  strict pattern match based transform during final graph re-shaping looks promising here.

> Hi @jatin-bhateja ，currently I'm looking at https://bugs.openjdk.org/browse/JDK-8290485, and noticed that you said the transformations for Reverse[bytes] are special that we cannot do the transformations when it is used by a VectorBlend. Could you please explain why? Per my understanding, the masked Reverse[bytes] with VectorBlend should also work, no matter what changes are applied to the Reverse[bytes], since we only need to make sure the non-masked lanes come from the first input, and the masked lanes from the second (Reverse[bytes]). Please correct me if I misunderstood. Thanks a lot!

Hi @XiaohongGong , I re-implemented this before JEP integration by introducing a new [Node flag: Flag_is_predicated_using_blend](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L788), this allowed us to move these transforms back to Idealization routines. Idea here was to prevent removing cascaded ReverseBytes if they are predicated, unless both the predicates comply. Thanks!

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

PR: https://git.openjdk.org/panama-vector/pull/182