On Mon, 1 Nov 2021 22:59:10 GMT, Vladimir Kozlov wrote:
> Yes, I am fine with new intrinsics for them.
All right, see new commit then.
-
PR: https://git.openjdk.java.net/jdk/pull/6184
On Mon, 1 Nov 2021 15:35:36 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Mon, 1 Nov 2021 18:44:53 GMT, Vladimir Kozlov 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:
On Mon, 1 Nov 2021 15:35:36 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Mon, 1 Nov 2021 13:08:05 GMT, Andrew Haley wrote:
> So we have _dsqrt and_dsqrt_strict, which must be functionally identical, but
> we provide both names because they're part of a public API. I think this
> deserves an explanatory comment in the code.
Yes, no problem, added comment near int
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
> giving failing intrinsics a second chance to match against the similar `Math`
> intrinsics. This has interesting consequence for matchers: we can match the
> native `StrictMath.sqrt` to non-native intrinsic for `Math.
