On Thu, 24 Apr 2025 23:03:09 GMT, Vladimir Ivanov <vliva...@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
