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

Reply via email to