On Fri, 6 Jun 2025 10:38:11 GMT, erifan wrote:
>> This patch optimizes the following patterns:
>> For integer types:
>>
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>> => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>> => (VectorMas
On Wed, 30 Apr 2025 11:57:32 GMT, Robbin Ehn wrote:
> I don't see any alternatives - if this approach is not liked, any suggestions?
The changes seems fine to me. It's just a pity that this would only work for
riscv for now.
I guess we don't have a better choice given current status of qemu-use
On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn wrote:
>> Hi, for you to consider.
>>
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not
>> implemented'" for SA
On Thu, 24 Apr 2025 23:29:28 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only symbol lookup for now. But it still e
On Sat, 19 Apr 2025 20:09:59 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding
>> tests are not turn on either.
>> 2. Some optimiza
On Fri, 11 Apr 2025 10:48:34 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding
>> tests are not turn on either.
>> 2. Some optimiza
On Fri, 11 Apr 2025 10:48:34 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding
>> tests are not turn on either.
>> 2. Some optimiza
On Thu, 10 Apr 2025 12:08:29 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding
>> tests are not turn on either.
>> 2. Some optimiza
On Mon, 31 Mar 2025 10:45:54 GMT, Robbin Ehn wrote:
>> Hi, for you to consider.
>>
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not
>> implemented'" for SA
On Wed, 9 Apr 2025 06:31:55 GMT, Robbin Ehn wrote:
> > > It's not some intermittently failure. The majority of them can't work as
> > > they use pstack, open core files, use PerfData, etc.. and expected it to
> > > be rv64. But core files, pstack are in host arch as we are running
> > > qemu-u
On Tue, 8 Apr 2025 10:29:38 GMT, Hamlin Li wrote:
> > Maybe we should check UseZicond and only enable UseCMoveUnconditionally &
> > ConditionalMoveLimit conditionally?
>
> Not sure what do you mean here.
Sorry for not being clear enough. I am suggesting this:
if (UseZicond) {
FLAG_SET_
On Fri, 28 Mar 2025 06:53:15 GMT, Robbin Ehn wrote:
> It's not some intermittently failure. The majority of them can't work as they
> use pstack, open core files, use PerfData, etc.. and expected it to be rv64.
> But core files, pstack are in host arch as we are running qemu-user. I can
> remo
On Mon, 7 Apr 2025 14:23:52 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding
> tests are not turn on either.
> 2. Some optimization of
On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn wrote:
> Hi, for you to consider.
>
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in
> emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'"
> f
On Sat, 8 Mar 2025 19:32:54 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early is that this is a large change, and the
On Thu, 19 Dec 2024 18:16:47 GMT, Severin Gehwolf wrote:
> @MBaesken @RealFYang Could you please test this PR since you originally ran
> into JDK-8346239 (this bug) and
> [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036). Thanks!
Yes, I can confirm that it works on my linux-aarch64 pl
On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote:
>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in
>>> all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing th
On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo
wrote:
>> Sorry, I also thought it matched the aarch64 one without checking.
>> @RealFYang should I change it for `hf.sp() + frame::link_offset` or just
>> leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::se
On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
>>
>>> 271: ? frame_sp + fsize - frame::sender_sp_offset
>>> 272: // we need to re-read fp because it may be an oop and we might
>>> have f
On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo
wrote:
>> Here's my suggested C2 change:
>>
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad
>> b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotsp
On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo
wrote:
>> Here's my suggested C2 change:
>>
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad
>> b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotsp
On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote:
>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in
>>> all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing th
On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo
wrote:
>> Sorry, I also thought it matched the aarch64 one without checking.
>> @RealFYang should I change it for `hf.sp() + frame::link_offset` or just
>> leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::se
On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
>>
>>> 271: ? frame_sp + fsize - frame::sender_sp_offset
>>> 272: // we need to re-read fp because it may be an oop and we might
>>> have f
On Wed, 4 Sep 2024 11:58:49 GMT, Jorn Vernee wrote:
> Were you able to reproduce the original issue on RISC-V?
Yeah. I can reproduce similar crash on linux-riscv64 platform running this new
test as well.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r17437
On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee wrote:
> As discussed in the JBS issue:
>
> FFM upcall stubs embed a `Method*` of the target method in the stub. This
> `Method*` is read from the `LambdaForm::vmentry` field associated with the
> target method handle at the time when the upcall stu
On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> Thanks!
>
> This is similar with previous JDK-8334396.
> Added some tests.
>
> ### Test
>
> | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBy
On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Thu, 19 Oct 2023 12:14:52 GMT, Ilya Gavrilin wrote:
>> Hi all, please review this changes into risc-v floating point copysign and
>> signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have
>> `fsgnj.x` instruction, which can implement this intrinsic
On Wed, 18 Oct 2023 17:35:58 GMT, Ilya Gavrilin wrote:
>> Hi all, please review this changes into risc-v floating point copysign and
>> signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have
>> `fsgnj.x` instruction, which can implement this intrinsic
On Tue, 17 Oct 2023 09:52:15 GMT, Ilya Gavrilin wrote:
>> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1682:
>>
>>> 1680: // use floating-point 1.0 with a sign of input
>>> 1681: is_double ? fsgnj_d(dst, one, src)
>>> 1682: : fsgnj_s(dst, one, src);
>>
>> What if the `
On Mon, 16 Oct 2023 21:14:39 GMT, Ilya Gavrilin wrote:
>> Hi all, please review this changes into risc-v floating point copysign and
>> signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have
>> `fsgnj.x` instruction, which can implement this intrinsic
On Fri, 13 Oct 2023 15:36:56 GMT, Ilya Gavrilin wrote:
> Hi all, please review this changes into risc-v floating point copysign and
> signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have
> `fsgnj.x` instruction, which can implement this intrinsic.
>
On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.
@minborg :
On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.
> Hi @minbo
On Thu, 9 Mar 2023 14:39:55 GMT, Feilong Jiang wrote:
> [JDK-8303604](https://bugs.openjdk.org/browse/JDK-8303604) fixes an issue
> with passing structs whose size is not a power of two on SysV and AArch64
> platforms. The same issue happens on RISC-V.
>
> Modifications are unnecessary for `ST
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
>>
On Mon, 16 Jan 2023 06:38:35 GMT, Feilong Jiang wrote:
>> Add experimental Foreign Function & Memory API support for RISC-V.
>>
>> For details of the FFM API RISC-V port please refer to [JBS
>> issue](https://bugs.openjdk.org/browse/JDK-8293841)
>>
>> Testing:
>>
>> - [x] jdk_foreign with rel
On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang wrote:
>> Add experimental Foreign Function & Memory API support for RISC-V.
>>
>> For details of the FFM API RISC-V port please refer to [JBS
>> issue](https://bugs.openjdk.org/browse/JDK-8293841)
>>
>> Testing:
>>
>> - [x] jdk_foreign with rel
On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov
wrote:
> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic
> turned out to be profitable on RISC-V using the same fclass instruction as
> for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it
> ad
On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov
wrote:
> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic
> turned out to be profitable on RISC-V using the same fclass instruction as
> for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it
> ad
On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that can
42 matches
Mail list logo
