On Wed, 8 Mar 2023 23:14:05 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Wed, 8 Mar 2023 22:49:42 GMT, Vladimir Kozlov wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534:
>>
>>> 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame
>>> 3533: __ ret(0);
>>> 3534:
>>
>> Do we really need to set up a stack frame for these
On Wed, 8 Mar 2023 23:14:05 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
> methods were implemented originally.
>
> Replaced
On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Wed, 8 Mar 2023 22:27:31 GMT, Dean Long wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove RISC-V port code for float16 intrinsics
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534:
>
>> 3532:
On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Wed, 8 Mar 2023 21:41:31 GMT, Vladimir Ivanov wrote:
> Or encapsulate the constant folding logic (along with the guard) into
> SharedRuntime and return Type* (instead of int/float scalar).
I take this particular suggestion back. `SharedRuntime` is compiler-agnostic
while `Type` is
On Wed, 8 Mar 2023 20:55:29 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/opto/convertnode.cpp line 171:
>>
>>> 169: if (t == Type::TOP) return Type::TOP;
>>> 170: if (t == Type::FLOAT) return TypeInt::SHORT;
>>> 171: if (StubRoutines::f2hf() == nullptr) return bottom_type();
>>
>>
On Wed, 8 Mar 2023 19:04:01 GMT, Vladimir Ivanov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove RISC-V port code for float16 intrinsics
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 451:
>
>>
On Wed, 8 Mar 2023 19:38:56 GMT, Vladimir Ivanov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove RISC-V port code for float16 intrinsics
>
> src/hotspot/share/opto/convertnode.cpp line 171:
>
>> 169:
On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
On Wed, 8 Mar 2023 01:53:14 GMT, Fei Yang wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
> methods were implemented originally.
>
> Replaced
On Tue, 7 Mar 2023 21:38:38 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
> Implemented `Float.floatToFloat16` and
On Tue, 7 Mar 2023 18:28:46 GMT, Jatin Bhateja wrote:
>> @sviswa7 I update changes based on your comments. Please, look:
>> [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4)
>
> Hi @vnkozlov , There is some discrepancy in results b/w
On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote:
>> Other than the minor comments above, the x86 side changes look good to me.
>
> @sviswa7 I update changes based on your comments. Please, look:
>
On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote:
>> Other than the minor comments above, the x86 side changes look good to me.
>
> @sviswa7 I update changes based on your comments. Please, look:
>
On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Tue, 7 Mar 2023 01:26:44 GMT, Sandhya Viswanathan
wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
> methods were implemented originally.
>
> Replaced
On Tue, 7 Mar 2023 01:59:25 GMT, Vladimir Kozlov wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931:
>>
>>> 3929: // For results consistency both intrinsics should be enabled.
>>> 3930: if
>>> (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) &&
>>>
On Tue, 7 Mar 2023 01:04:00 GMT, Sandhya Viswanathan
wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these
On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>
On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>
On Tue, 7 Mar 2023 00:52:37 GMT, Vladimir Kozlov wrote:
> Note, I removed `ConvF2HFNode::Identity()` optimization because tests show
> that it produces different NaN results due to skipped conversion.
Yes, removing the Identity optimization is correct. It doesn't hold for NaN
inputs.
On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>
On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>
On Tue, 7 Mar 2023 00:19:03 GMT, Sandhya Viswanathan
wrote:
> For x86 32-bit also things are consistent across. Only the SharedRuntime
> optimization doesnt happen for x86 32bit as StubRoutines::hf2f() and
> StubRoutines::f2hf() are set as null. The fallback is handled correctly in
>
On Mon, 6 Mar 2023 23:54:44 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>
On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote:
> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
Implemented `Float.floatToFloat16` and
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan
wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant
> expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point
> instructions. This happens across
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan
wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant
> expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point
> instructions. This happens across
On Wed, 22 Feb 2023 09:46:59 GMT, Doug Simon wrote:
> > That said, I think it is reasonable on a given JVM invocation if
> > Float.floatToFloat16(f) gave the same result for input f regardless of in
> > what context it was called.
>
> Yes, I'm under the impression that for math API methods
On Wed, 22 Feb 2023 21:21:42 GMT, Vladimir Kozlov wrote:
>>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
>>> three mechanisms for implementing this functionality:
>>>
>>> 1. The interpreted Java code
>>>
>>> 2. The compiled non-intrinisc sharedRuntime
On Wed, 22 Feb 2023 21:21:42 GMT, Vladimir Kozlov wrote:
>>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
>>> three mechanisms for implementing this functionality:
>>>
>>> 1. The interpreted Java code
>>>
>>> 2. The compiled non-intrinisc sharedRuntime
On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy wrote:
>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
>> three mechanisms for implementing this functionality:
>>
>> 1. The interpreted Java code
>> 2. The compiled non-intrinisc sharedRuntime code
>> 3. The compiler
On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy wrote:
>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
>> three mechanisms for implementing this functionality:
>>
>> 1. The interpreted Java code
>> 2. The compiled non-intrinisc sharedRuntime code
>> 3. The compiler
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan
wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant
> expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point
> instructions. This happens across
On Wed, 22 Feb 2023 04:03:02 GMT, David Holmes wrote:
>> Change the java/lang/float.java and the corresponding shared runtime
>> constant expression evaluation to generate QNaN.
>> The HW instructions generate QNaNs and not SNaNs for floating point
>> instructions. This happens across double,
On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy wrote:
> That said, I think it is reasonable on a given JVM invocation if
> Float.floatToFloat16(f) gave the same result for input f regardless of in
> what context it was called.
Yes, I'm under the impression that for math API methods like this,
On Wed, 22 Feb 2023 04:03:02 GMT, David Holmes wrote:
> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
> three mechanisms for implementing this functionality:
>
> 1. The interpreted Java code
>
> 2. The compiled non-intrinisc sharedRuntime code
>
> 3.
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan
wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant
> expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point
> instructions. This happens across
On Wed, 22 Feb 2023 03:46:42 GMT, Joe Darcy wrote:
> I'd like to see a more informative description of the problem:
>
> "float16 NaN values handled differently with and without intrinsification"
>
> If that is issue reported, it may not be a problem as opposed to
>
> "incorrect value returned
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan
wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant
> expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point
> instructions. This happens across
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan
wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant
> expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point
> instructions. This happens across
Change the java/lang/float.java and the corresponding shared runtime constant
expression evaluation to generate QNaN.
The HW instructions generate QNaNs and not SNaNs for floating point
instructions. This happens across double, float, and float16 data types. The
most significant bit of mantissa
56 matches
Mail list logo
