On Fri, 13 May 2022 08:24:24 GMT, Jatin Bhateja <jbhat...@openjdk.org> wrote:
>> src/hotspot/share/opto/c2compiler.cpp line 521:
>>
>>> 519: if (!Matcher::match_rule_supported(Op_SignumF)) return false;
>>> 520: break;
>>> 521: case vmIntrinsics::_VectorComExp:
>>
>> Why `_VectorComExp` intrinsic is special? Other vector intrinsics are
>> handled later and in a different manner.
>>
>> What about `ExpandV` case?
>
> It was an attempt to facilitate in-lining of these APIs over targets which do
> not intrinsify them. I agree its not a generic fix since three APIs are
> piggybacking on same entry point and without the knowledge of opcode it will
> be inappropriate to take any call at this place, lazy intrinsification gives
> opportunity for some of the predications to concertize as compilation happens
> under closed world assumptions.
Still not clear why the code is shaped the way it is.
`Matcher::match_rule_supported_vector()` already checks that there are relevant
matching rules.
The checks require both `CompressM` and `CompressV` to be present to enable the
intrinsic. Is it important?
Also, it doesn't take `EnableVectorSupport` into account while all other vector
intrinsics respect it.
>> src/hotspot/share/opto/compile.cpp line 3416:
>>
>>> 3414:
>>> 3415: case Op_ReverseBytesV:
>>> 3416: case Op_ReverseV: {
>>
>> Can you elaborate, please, why it is performed so late in the optimization
>> phase (at the very end during graph reshaping) and not during GVN?
>
> Its more of a chicken-egg problem here, for masked reverse operation, Reverse
> IR node is followed by a Blend Node, thus in such a case doing an eager
> Identity transform in Reverse::Identity will not work, also deferring this to
> blend may also not work since it could be a non-masked reverse operation, we
> could have handled it as a special case in inline_vector_nary_operation, but
> handling such special case in final graph reshaping looked more appropriate.
>
> https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080
Do you mean it's important to apply the transformation at the right node (pick
the right node as the root) and it is hard to make a decision during GVN?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8425
