RFR: 8353786: Migrate Vector API math library support to FFM API [v13]

[Jatin Bhateja]

On Thu, 24 Apr 2025 23:03:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 563:
>> 
>>> 561:     debug_name = debug_name_oop->const_oop()->as_instance()->java_lang_String_str(buf, buflen);
>>> 562:   }
>>> 563:   Node* vcall = make_runtime_call(RC_VECTOR,
>> 
>> By generating an upfront CallLeafVectorNode, we may miss out on performing any GVN-style optimization for trigonometric identities like the following. do you think creating a macro node which can lazily be expanded to call node during macro expansion will help.
>> 
>> arcsin(sin(x)) => x
>> arccos(cos(x)) => x
>> sin(arcsin(x) => x
>> cos(arccos(x) => x
>
> It does look attractive, but macro expansion-based solution requires JVM to internalize such operations and their properties. 
> 
> IMO a higher-level solution based on more generic JVM primitives would enable libraries to properly annotate their operations in Java bytecodes/class files, so C2 can perform such type of transformations without the need to intrinsify each individual operation first. (Think of [JDK-8218414](https://bugs.openjdk.org/browse/JDK-8218414) / [JDK-8347901](https://bugs.openjdk.org/browse/JDK-8347901) on steroids.)

I agree, this is a typical graph transform which cannot be applied currently because we are generating CallLeafVectorNode upfront during parsing, If we prevent intrinsification then compiler will attempt inlining, generating a much complex graph shape which may not be reducible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059911738