On Thu, 27 Jun 2024 11:53:38 GMT, Fei Gao wrote:
>> in progress...
>
> Hi @Hamlin-Li , thanks for your work.
>
> I tried to run benchmarks,
> [FloatMaxVector](https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/FloatMaxVecto
On Thu, 6 Jun 2024 07:52:02 GMT, Hamlin Li wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update header files for arm
>
> in progress...
Hi @Hamlin-Li , thanks for your work.
I tried to run benchmarks,
[FloatMaxVe
On Wed, 8 May 2024 17:41:23 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>>
>> Compared with previous
> Hi,
> Can you help to review the patch?
> This pr is based on previous work and discussion in [pr
> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
> 18294](https://github.com/openjdk/jdk/pull/18294).
>
> Compared with previous prs, the major change in this pr is to integrate the
> sou
On Tue, 6 Feb 2024 08:20:39 GMT, Magnus Ihse Bursie wrote:
> I'd just hate to see all this work go to waste.
Same here!
-
PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929780538
On Mon, 11 Dec 2023 18:25:09 GMT, Ludovic Henry wrote:
>> @theRealAph
>>> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF
>>> support?
>>
>> I can't say anything for sure, but I picked up some positive vibes from our
>> internal chat. I think the idea was that libsl
On Mon, 4 Dec 2023 11:58:55 GMT, Magnus Ihse Bursie wrote:
> I can't say anything for sure, but I picked up some positive vibes from our
> internal chat. I think the idea was that libsleef could potentially cover up
> vector math for all platforms that the current Intel lib solution is missing
On Fri, 1 Dec 2023 16:26:02 GMT, Magnus Ihse Bursie wrote:
>> Xiaohong Gong has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains ten additional
>> co
On Tue, 5 Dec 2023 13:00:04 GMT, Magnus Ihse Bursie wrote:
> So you need to check both the flag and the header file? Oh well, then this is
> probably as good as it gets.
Yes, we have to check both the flag and the header file.
-
PR Comment: https://git.openjdk.org/jdk/pull/16234#i
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong wrote:
>> The final thing we need to resolve properly is the SVE compiler test.
>>
>> @theRealAph says:
>>> arm_sve.h is part of GCC. It was added to GCC in 2019.
>>
>> A more relevant question is what version of gcc it was added, and if that
>>
On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong wrote:
>> The final thing we need to resolve properly is the SVE compiler test.
>>
>> @theRealAph says:
>>> arm_sve.h is part of GCC. It was added to GCC in 2019.
>>
>> A more relevant question is what version of gcc it was added, and if that
>>
On Fri, 1 Dec 2023 16:49:28 GMT, Andrew Haley wrote:
>> Oh, and:
>>
>> If we can't trust SLEEF not to break the ABI we're using, we should not be
>> using SLEEF.
>
>> @theRealAph You are making good points.
>>
>> You are basically saying: "we don't need any configure support for libsleef,
>>
On Fri, 1 Dec 2023 16:45:49 GMT, Magnus Ihse Bursie wrote:
> The final thing we need to resolve properly is the SVE compiler test.
>
> @theRealAph says:
>
> > arm_sve.h is part of GCC. It was added to GCC in 2019.
>
> A more relevant question is what version of gcc it was added, and if that
>
On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley wrote:
>> Xiaohong Gong has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains ten additional
>> commits
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley wrote:
>> Xiaohong Gong has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains ten additional
>> commits
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
> Currently the vector floating-point math APIs like
> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
> which causes large performance gap on AArch64. Note that those APIs are
> optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1].
> To close th
21 matches
Mail list logo
