On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote:
>>> > I can't tell what problem we're trying to solve by not simply checking in
>>> > the source code, in its preferred form, to the OpenJDK tree. Thhis has
>>> > practical advantages to do with traceability and security, and
>>> > in-prin
On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote:
> Given the Sleef build system currently uses cmake, we would have two choices
> to build the header files as part of the OpenJDK build system
I don't think that anyone is proposing to do that, so we can discount it
altogether.
> However,
On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote:
> I think so, along with scripting that generates the preprocessed file we use.
> It might be the case that there are some sleef files not used at all they
> could be omitted, but I'm not sure it would be useful, and from a
> traceability
On Mon, 15 Jul 2024 17:00:13 GMT, Andrew Haley wrote:
> > > I can't tell what problem we're trying to solve by not simply checking in
> > > the source code, in its preferred form, to the OpenJDK tree. Thhis has
> > > practical advantages to do with traceability and security, and
> > > in-princ
On Mon, 15 Jul 2024 14:42:45 GMT, Hamlin Li wrote:
> > I can't tell what problem we're trying to solve by not simply checking in
> > the source code, in its preferred form, to the OpenJDK tree. Thhis has
> > practical advantages to do with traceability and security, and in-principle
> > reason
On Wed, 10 Jul 2024 10:48:19 GMT, Andrew Haley wrote:
> I can't tell what problem we're trying to solve by not simply checking in the
> source code, in its preferred form, to the OpenJDK tree. Thhis has practical
> advantages to do with traceability and security, and in-principle reasons to
>
On Mon, 8 Jul 2024 16:20:40 GMT, Andrew Haley wrote:
> I finally did some measurements.
Thanks for testing it!
> It would be nice if the JMH test were part of this patch.
OK, I can do that later.
>
> It mostly looks good, but I can see an odd regression of DoubleMaxVector.TANH
> (by 39%) o
On Mon, 8 Jul 2024 16:40:50 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into sleef-aarch64-integrate-source
>> - merge master
>> - sleef 3.6.1
On Mon, 8 Jul 2024 16:40:50 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into sleef-aarch64-integrate-source
>> - merge master
>> - sleef 3.6.1
On Mon, 1 Jul 2024 16:54:55 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).
>> * NOTE: This pr depends on
On Mon, 1 Jul 2024 16:54:55 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).
>> * NOTE: This pr depends on
On Mon, 8 Jul 2024 13:36:36 GMT, Andrew Haley wrote:
> There is something that makes me nervous. The big slab of preprocessed code
> in libvectormath/sleefinline_rvvm1.h is problematic. Firstly, in all open
> source software the code should be the preferred form:
>
> "The source code must be t
On Mon, 1 Jul 2024 16:54:55 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
On Mon, 8 Jul 2024 08:43:34 GMT, Andrew Haley wrote:
> That doesn't work.
>
> ```
> Running tests using MICRO control variable
> 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions
> -XX:+EnableVectorSupport -XX:+UseVectorStubs'
> Unknown test selection:
> 'org.openjd
On Mon, 1 Jul 2024 16:54:55 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
On Fri, 5 Jul 2024 17:44:14 GMT, Andrew Haley wrote:
> I also had problems with javac running out of heap space, which was very odd.
> I fixed it with this:
>
> ```
> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
> index 8d272c28ad5..617ccfd8fff 100644
> --- a/make/autoconf
On Mon, 1 Jul 2024 16:54:55 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 Fri, 1 Mar 2024 15:10:30 GMT, Magnus Ihse Bursie wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix potential attribute issue
>
> Iirc, your assessment is right; the code should be ready for integration; I
>
On Thu, 7 Dec 2023 09:30:01 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 Thu, 7 Dec 2023 09:30:01 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 Thu, 7 Dec 2023 09:30:01 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 Thu, 7 Dec 2023 09:30:01 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 Thu, 7 Dec 2023 09:30:01 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 Thu, 7 Dec 2023 09:30:01 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, 8 Dec 2023 00:50:59 GMT, Xiaohong Gong wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix potential attribute issue
>
>> Build changes finally look good. Great, actually! Thanks for persisting,
>> despit
On Thu, 7 Dec 2023 09:30:01 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 Thu, 7 Dec 2023 09:30:01 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
29 matches
Mail list logo
