On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to the way Java modules work, t
On Tue, 31 Oct 2023 13:05:44 GMT, Robbin Ehn wrote:
> Hi, please consider.
>
> insn_options[0] is set to empty string if there is no options (NULL or empty
> strings).
> Checking it for empty string should cover both cases, caller option is NULL
> or caller option is empty string.
>
> Tested
On Wed, 1 Nov 2023 11:52:20 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> insn_options[0] is set to empty string if there is no options (NULL or empty
>> strings).
>> Checking it for empty string should cover both cases, caller option is NULL
>> or caller option is empty string.
>>
>>
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
Hi,
Can you help to review this patch?
Thanks
This is a continuation of work based on [1] by @XiaohongGong, most work was
done in that pr. In this new pr, just rebased the code in [1], then added some
minor changes (renaming of calling method, add libsleef as extra lib in CI
cross-build on aarc
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
>
> [1] https://github.com/openjdk/jdk/pull/16234
>
> ## Regression Test
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ## Performance Test
> Previously, @XiaohongGong has shared the data:
> https://github.com/openjdk/jdk/pull/16234#issueco
On Thu, 14 Mar 2024 08:59:09 GMT, Ludovic Henry wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix variable name in github workflow
>
> .github/workflows/build-cross-compile.yml line 13
> [1] https://github.com/openjdk/jdk/pull/16234
>
> ## Regression Test
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ## Performance Test
> Previously, @XiaohongGong has shared the data:
> https://github.com/openjdk/jdk/pull/16234#issueco
On Thu, 14 Mar 2024 15:29:51 GMT, Andrew Haley wrote:
> Hi, thanks for continuing with this.
Thanks for the comments
> As this is similar to SVML, comments applies to x86 also:
>
> * There is no way to stop the VM from trying to load vmath ?
No official way, but deleting libvmath.so will have
On Thu, 14 Mar 2024 12:23:17 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix variable name in github workflow
>
> src/jdk.incubator.vector/linux/native/libvma
On Thu, 14 Mar 2024 15:25:54 GMT, Andrew Haley wrote:
> > ```
> > * at build time
> >
> > * with/without sleef
> > * with/without sve support
> > ```
>
> What is the relevance of SVE support at build time? Should it matter what the
> build machine is?
>
> Its important to realize that a
On Thu, 14 Mar 2024 15:29:51 GMT, Andrew Haley wrote:
> > Hi, thanks for continuing with this.
> > As this is similar to SVML, comments applies to x86 also:
> > ```
> > * There is no way to stop the VM from trying to load vmath ?
> > There is both a UseNeon and a UseSVE, if I set both to false
> [1] https://github.com/openjdk/jdk/pull/16234
>
> ## Regression Test
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ## Performance Test
> Previously, @XiaohongGong has shared the data:
> https://github.com/openjdk/jdk/pull/16234#issueco
On Fri, 15 Mar 2024 11:55:14 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - rename
>> - resolve magicus's comments
>
> src/jdk.in
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Fri, 15 Mar 2024 11:25:37 GMT, Hamlin Li wrote:
> > * There is no way to stop the VM from trying to load vmath ?
>
> No official way, but deleting libvmath.so will have a same effect. I'm not
> sure if avoiding loading vmath is necessary for typical users, if it turns
On Thu, 21 Mar 2024 15:43:28 GMT, Magnus Ihse Bursie wrote:
>>> > The problem I see is that J. Random Java User has no way to know if SLEEF
>>> > is making their program faster without running benchmarks. They'll put
>>> > SLEEF somewhere and hope that Java uses it.
>>>
>>> Please kindly corre
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
> > > What is the relevance of SVE support at build time? Should it matter what
> > > the build machine is?
> >
> >
> > My understanding is that we need a compiler that supports
> > `-march=armv8-a+sve`; otherwise we can't build the redirect
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Fri, 22 Mar 2024 12:42:04 GMT, Magnus Ihse Bursie wrote:
> > Ah, it'll only be the redirect library that's compiled with
> > -march=armv8-a+sve Forget that.
>
> But that raises an interesting question. What happens if you try to load a
> library compiled with `-march=armv8-a+sve` on a non-S
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
>>> What is the relevance of SVE support at build time? Should it matter what
>>> the build machine is?
>>
>> My understanding is that we need a compiler that supports
>> `-march=armv8-a+sve`; otherwise we can't build the redirect library
>>
On Mon, 25 Mar 2024 09:24:16 GMT, Magnus Ihse Bursie wrote:
> > > But that raises an interesting question. What happens if you try to load
> > > a library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the
> > > ELF flagged to require SVE so it will fail to load? I'm hoping this is
On Mon, 25 Mar 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
> > A question about the licensing: how long does it take to finish the legal
> > process of the sleef licence?
>
> I am not sure this is a relevant question anymore. As I said, the libsleef
> build system seems virtually impossible t
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Wed, 27 Mar 2024 14:47:00 GMT, Magnus Ihse Bursie wrote:
> At this point, I think I am not really qualified to continue the discussion.
>
> I will ask around inside Oracle to see if I can find someone who better
> understands the implications of the suggested libsleef integration (with or
>
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Thu, 28 Mar 2024 18:41:03 GMT, Paul Sandoz wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
> Hamlin, thank you for working on this. I think integrating a sub-set of
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
source of sleef (fo
On Thu, 28 Mar 2024 18:41:03 GMT, Paul Sandoz wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
> Hamlin, thank you for working on this. I think integrating a sub-set of
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Thu, 14 Mar 2024 08:48:11 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> Thanks
>
> This is a continuation of work based on [1] by @XiaohongGong, most work was
> done in that pr. In this new pr, just rebased the code in [1], then added
> some minor
On Wed, 3 Apr 2024 19:23:01 GMT, Magnus Ihse Bursie wrote:
> Just a quick question after giving this a glance: My understanding was that
> the normal libsleef build set a lot of compiler options, e.g. disabling
> built-in maths etc. You don't seem to set any of these. Have you determined
> tha
ly, e.g.
> remove some uncessary files or changes especially in make dir of jdk.
>
> Besides of the code changes, one important task is to handle the legal
> process.
>
> Thanks!
Hamlin Li has updated the pull request incrementally with two additional
commits since the last revi
On Thu, 4 Apr 2024 16:47:44 GMT, Magnus Ihse Bursie wrote:
> Build libsleef using their cmake system and look at the compile command line.
> (You do this by `VERBOSE=1 cmake` IIRC). Then you can see what flags they are
> using. This is what I was referring to as "normal libsleef build". I notic
On Thu, 4 Apr 2024 21:55:54 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> make/modules/
On Fri, 5 Apr 2024 10:45:24 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>> Thanks
On Fri, 5 Apr 2024 12:17:17 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).
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
> Thank you for the update and for working on this in general.
>
> I've started working on JDK-8329816, preparing the change for the SLEEF
> specific part of the change. Specifically, I'm currently planning on
> including the three SLEEF
On Wed, 10 Apr 2024 09:24:09 GMT, Hamlin Li wrote:
> > Thank you for the update and for working on this in general.
> > I've started working on JDK-8329816, preparing the change for the SLEEF
> > specific part of the change. Specifically, I'm currently planning on
&
ly, e.g.
> remove some uncessary files or changes especially in make dir of jdk.
>
> Besides of the code changes, one important task is to handle the legal
> process.
>
> Thanks!
Hamlin Li has updated the pull request incrementally with one additional commit
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> Thank you for t
On Thu, 11 Apr 2024 10:36:03 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/pul
On Thu, 11 Apr 2024 10:36:03 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/pul
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Thu, 11 Apr 2024 10:36:03 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/pul
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> Thank you for t
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
> separately
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
> separately
On Mon, 13 May 2024 17:33:20 GMT, Mikael Vidstedt wrote:
> Looks like that change is not yet in a released version of SLEEF, and in
> particular not in 3.6.
>
> We do need updated approvals when we pick up new versions. Since we've gone
> through the process once it's typically easier/faster t
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
> separately
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).
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.108 |
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/incub
On Fri, 17 May 2024 16:45:19 GMT, Mikael Vidstedt wrote:
> Thank you Hamlin. I'll try to keep my eyes open for the announcement of the
> upcoming SLEEF release but do feel free to notify me if you see it first!
Thank you @vidmik , sure, I will do it.
> I, too, envision that we'll be importing
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
> separately
On Wed, 22 May 2024 09:31:27 GMT, Magnus Ihse Bursie wrote:
> So you'd need a different copy of sleef for each platform?
I think it's one or more.
> The files you have put in linux/native/libvectormath, what platform are they
> for? Should we not put them in a platform-specific subdirectory?
On Thu, 23 May 2024 10:40:26 GMT, Magnus Ihse Bursie wrote:
>>> So you'd need a different copy of sleef for each platform?
>>
>> I think it's one or more.
>>
>>> The files you have put in linux/native/libvectormath, what platform are
>>> they for? Should we not put them in a platform-specific
On Thu, 23 May 2024 16:06:42 GMT, Magnus Ihse Bursie wrote:
>> I think both `sleefinline_advsimd.h` and `sleefinline_sve.h` are specific
>> for arm.
>> In the future, on riscv the corresponding file name will be
>> `sleefinline_rvvm1.h`.
>>
>> Only `misc.h` is a generic file shared among platf
On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote:
>> In case you need it and avoid to generate yourself, I've generated sleef
>> inline header of 3.6.1 for riscv, it's at
>> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe8819898
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.108 |
On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote:
>> In case you need it and avoid to generate yourself, I've generated sleef
>> inline header of 3.6.1 for riscv, it's at
>> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe8819898
On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>> separa
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, 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 Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>> separa
102.033 | 2.408
> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559
> | 2.865 | 296.741 | 103.18 | 2.876
> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 |
> 3.967 | 195.891 | 49.771 | 3.936
> Float128Vector.ATAN2 | 1024 |
102.033 | 2.408
> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559
> | 2.865 | 296.741 | 103.18 | 2.876
> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 |
> 3.967 | 195.891 | 49.771 | 3.936
> Float128Vector.ATAN2 | 1024 |
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 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, 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 Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> skip TANH
>
>> Currently,
>>
>> * in [8329816: Add SLEEF version 3.6
On Tue, 16 Jul 2024 09:48:55 GMT, Andrew Haley wrote:
>>> Currently,
>>>
>>> * in [8329816: Add SLEEF version 3.6.1
>>> #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef
>>> inline headers from sleef 3.6.1, which is tagged in sleef repo.
>>>
>>> * And with the
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 Tue, 16 Jul 2024 10:42:24 GMT, Andrew Haley wrote:
> We're only a couple of weeks away from the summit. What would be a long time?
OK, then let's wait for it.
-
PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230591233
On Thu, 18 Jul 2024 20:50:14 GMT, fitzsim wrote:
> It is possible to regenerate `sleefinline_advsimd.h` and `sleefinline_sve.h`
> with some new OpenJDK build logic and only the following fifteen SLEEF source
> files:
>
> ```
> 32K ./src/jdk.incubator.vector/linux/native/sleef/src/arch/helper
On Tue, 23 Jul 2024 13:55:06 GMT, fitzsim wrote:
> To check this, I
> [added](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-2/)
> the `riscv64` `CMake` steps to `SleefCommon.gmk`.
>
> I had intended to factor out `SetupSleefHeader` anyway for `aarch64`, to
> eliminate copy-n
On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote:
>> In case you need it and avoid to generate yourself, I've generated sleef
>> inline header of 3.6.1 for riscv, it's at
>> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe8819898
On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>> separa
On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
t; 170: // Todo UseCompactObjectHeaders
>>
>> Can I ask, will this pr fullly support riscv?
>
> @Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet.
> To avoid duplicate work, please let me know if anyone is interested or has
> been worki
gt;>
>>> Not because I didn't think it was feasible to implement, but because of the
>>> future maintenance burden.
>>
>> I agree with @erikj79, in particular the above 3 points.
>>
>> Shall we be ready to move forward? Or we're still blocke
nd to
>> clarify further about `plan/logic` mentioned above?
>
> @Hamlin-Li Thank you for taking it on!
>
> Part of the work is figuring out exactly what exactly we want - see the
> comments from @erikj79 and @theRealAph in this PR for inspiration. In
> particular, we'
On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>> separa
On Wed, 28 Aug 2024 19:36:28 GMT, Erik Joelsson wrote:
> > 3]. scripts to transfering from 1] to 2], and necessary documents, e.g.
> > record which tag of sleef to use, .
>
> In addition to the tag, we should include the full git hash as well. A tag
> can be moved, but it's very hard to fake a
On Thu, 29 Aug 2024 12:22:32 GMT, Magnus Ihse Bursie wrote:
> ```
> ${JDK_ROOT}/src
> |-- jdk.incubator.vector/linux/native/libsleef
> |-- README.md
> |-- upstream/
>|-- ... # original sleef source (trimmed or not)
> |-- generated/
>|-- misc.h
>
On Thu, 29 Aug 2024 23:07:16 GMT, Magnus Ihse Bursie wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
> separat
On Fri, 30 Aug 2024 10:59:55 GMT, Magnus Ihse Bursie wrote:
> Basically, under the `$(eval $(call SetupJdkLibrary, BUILD_LIBVECTORMATH`
> call, you add the line:
>
> ```
> EXTRA_SRC := libsleef/generated, \
> ```
>
> and that should be it.
Thanks!
> However, I see that you also manipula
On Fri, 30 Aug 2024 16:57:18 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>> sep
On Mon, 9 Sep 2024 14:08:53 GMT, Roman Kennke wrote:
>> Yes, I'm interested in it. Thanks for raising the discussion. :)
>
> If anybody is doing it, please send me a patch, or we can do it as a
> follow-up PR.
Thanks. I'll send it to you if I finish it in time, otherwise I will do it in a
sepa
On Wed, 2 Aug 2023 06:55:40 GMT, Ludovic Henry wrote:
> Currently, RISC-V differs from other platforms in that it requires the
> linkage to libatomic.so to support sub-word atomic operations. However,
> because it is linked dynamically, it will depend on the installation of
> libatomic.so on t
On Tue, 26 Sep 2023 12:04:49 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> latomic is used for non native atomic operation which causes problems with
> extra dependency.
> This have been fixed in recent gcc, so latomic is no longer needed.
>
> Added new gtest, passes t1 on vf2/qemu.
N
On Tue, 15 Oct 2024 11:04:40 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update make/autoconf/flags-cflags.m4
>>
>> Co-authored-by: Magnus
P_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions
> -XX:+EnableVectorSupport -XX:+UseVectorStubs'
> * -intrinsic:
> 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions
> -XX:+EnableVectorSupport -XX:-UseVectorStubs'
>
> ### Performan
On Thu, 19 Sep 2024 15:01:26 GMT, Hamlin Li wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2'
>> i
1 - 100 of 161 matches
Mail list logo
