On Mon, 1 Nov 2021 18:44:53 GMT, Vladimir Kozlov <[email protected]> wrote:
> Removing intrinsics for StrictMatch `min/max` methods may prevent them from
> inlining if they are not hot when caller is compiled.
Would you like me to leave them instead? That would mean we introduce these new
intrinsic definitions:
/* StrictMath intrinsics, similar to what we have in Math. */
\
do_intrinsic(_min_strict, java_lang_StrictMath, min_name,
int2_int_signature, F_S) \
do_intrinsic(_max_strict, java_lang_StrictMath, max_name,
int2_int_signature, F_S) \
do_intrinsic(_minF_strict, java_lang_StrictMath, min_name,
float2_float_signature, F_S) \
do_intrinsic(_maxF_strict, java_lang_StrictMath, max_name,
float2_float_signature, F_S) \
do_intrinsic(_minD_strict, java_lang_StrictMath, min_name,
double2_double_signature, F_S) \
do_intrinsic(_maxD_strict, java_lang_StrictMath, max_name,
double2_double_signature, F_S) \
/* Special flavor of dsqrt intrinsic to handle the "native" method in
StrictMath. Otherwise the same as in Math. */ \
do_intrinsic(_dsqrt_strict, java_lang_StrictMath, sqrt_name,
double_double_signature, F_SN) \
-------------
PR: https://git.openjdk.java.net/jdk/pull/6184
