RFR: 8305324: C2: Wrong execution of vectorizing Interger.reverseBytes [v4]

Vladimir Kozlov kvn at openjdk.org
Tue Apr 11 17:55:35 UTC 2023


On Tue, 11 Apr 2023 17:07:36 GMT, Daohan Qu <duke at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 440:
>> 
>>> 438: // of its higher order bits/bytes
>>> 439: bool VectorNode::requires_higher_order_bits_of_integer(int opc) {
>>> 440:   if (is_shift_opcode(opc) && opc != Op_LShiftI) {
>> 
>> Checking Op_LShiftI here will change behavior for `Short s = LShiftI(LoadB)` case and similar. May be it is okay and previous code worked because we did not vectorize due to different sizes of destination and Load.
>
> Thanks for your review. Yes, I see. AFAICS, the if-condition calling this function wants to check whether higher order bits are needed. So I distill the condition content into a function. The `Op_LShiftI` is excluded since it doesn't need such info. Do I miss something? Or should the if-condition have checked more than what I thought?

What I am trying to say is that before this change `vt` will be set to `velt_type(load)` even if `in` is `LShiftI` node. With your changes `vt` will stay `== vtn` if  `in` is `LShiftI` node.  `velt_type(load)` could be different from `vtn` and as result your change may introduce difference in code generation in other than `ReverseBytesI` cases.
This needs to be tested to see if number of generated vectors is not reduced for such cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13406#discussion_r1163152069


More information about the hotspot-compiler-dev mailing list