> 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, 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], then added
>> some minor changes (renami
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 SLEEF
> is valuable (not all
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 SLEEF
> is valuable (not all
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], then added
>> some minor changes (renami
On Mon, 25 Mar 2024 15:13:54 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
>> > > But that raises an interesting question. What happens if you try to load
>> > > a library compi
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
On Mon, 25 Mar 2024 20:19:04 GMT, Hamlin Li wrote:
> But anyway, it's a furture incremental solution after this pr, am I right? Or
> are we going to change direction?
I'm honestly not sure what is the right way forward. It seems we all agree that
this PR is not the end solution we want. So the
On Mon, 25 Mar 2024 20:19:04 GMT, Hamlin Li wrote:
> It's not necessary to integrate libsleef build sysstem into jdk, we just need
> to integrate the final sources (generated by sleef cmake) into jdk. I have
> tested it, it works.
That is an interesting approach. It will raise the bar for upda
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 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 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], then added
>> some minor changes (renami
On Fri, 22 Mar 2024 15:30:35 GMT, Hamlin Li 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 the case
> > -
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], then added
>> some minor changes (renami
On Fri, 22 Mar 2024 15:27:07 GMT, Hamlin Li 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 to integrate into t
On Fri, 22 Mar 2024 15:22:57 GMT, Hamlin Li wrote:
> For ACLE, it's supported in [10.1](https://gcc.gnu.org/gcc-10/changes.html)
Do this PR require ACLE?
-
PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2017530218
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 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, 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], then added
>> some minor changes (renami
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, 22 Mar 2024 12:31:53 GMT, Andrew Haley 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-SVE system? Is th
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 Fri, 22 Mar 2024 12:31:01 GMT, Andrew Haley 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 redire
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
On Fri, 22 Mar 2024 08:51:47 GMT, Andrew Haley wrote:
>> @theRealAph Are you saying that bundling the source code of libsleef is a
>> hard requirement from your side to accept this code into the JDK?
>>
>> I'm not against it, I just want to understand what we're talking about here.
>>
>> In g
On Fri, 22 Mar 2024 10:22:54 GMT, Magnus Ihse Bursie 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 librar
On Fri, 15 Mar 2024 16:58:06 GMT, Andrew Haley 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 properly. But
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 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 Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley wrote:
>>> If there was some kind of plan, with evidence of the intention to do
>>> something to get this valuable tech into people's hands in a form they can
>>> use, sure. But as you can tell, I think this may rot because no one will be
>>> able
On Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley wrote:
>>> If there was some kind of plan, with evidence of the intention to do
>>> something to get this valuable tech into people's hands in a form they can
>>> use, sure. But as you can tell, I think this may rot because no one will be
>>> able
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], then added
>> some minor changes (renami
On Tue, 19 Mar 2024 17:00:48 GMT, Hamlin Li 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 correct me if I misunder
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
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], then added
>> some minor changes (renami
> 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 cro
On Thu, 23 Nov 2023 14:05:51 GMT, Magnus Ihse Bursie wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments in build system
>
> make/autoconf/lib-vmath.m4 line 70:
>
>> 68: if test "x$SYS
On Tue, 28 Nov 2023 01:37:01 GMT, Xiaohong Gong wrote:
>>> In fact, I am not even sure why it seems to the PR author to be a good idea
>>> to let the default be dependent on the build machine at all. My personal
>>> opinion is that it would be better to select either "SVE enabled" or "SVE
>>>
On Mon, 27 Nov 2023 16:43:09 GMT, Andrew Haley wrote:
>> Apparently the situation is this: If your build machine happens to have SVE,
>> then you will get SVE support in the vmath library. The SVE support will be
>> used during runtime if the machine you run on has SVE support.
>>
>> If your b
On Mon, 27 Nov 2023 15:22:32 GMT, Magnus Ihse Bursie wrote:
> In fact, I am not even sure why it seems to the PR author to be a good idea
> to let the default be dependent on the build machine at all. My personal
> opinion is that it would be better to select either "SVE enabled" or "SVE
> dis
On Mon, 27 Nov 2023 15:11:32 GMT, Andrew Haley wrote:
>> You still need to separate out the SVE detection from the libsleef code, and
>> provide a way to enable/disable it from the configure command line. It is
>> not okay to auto-detect if features should be turned on or off by default,
>> bu
On Mon, 27 Nov 2023 14:59:23 GMT, Magnus Ihse Bursie wrote:
> You still need to separate out the SVE detection from the libsleef code, and
> provide a way to enable/disable it from the configure command line.
Why? I don't think this should be a build-time option at all, because it puts
the peo
On Mon, 27 Nov 2023 10:28:45 GMT, Andrew Haley wrote:
>> We have to use this c-compiler option to build out the SVE ABIs (e.g.
>> `svfloat32_t sinfx_u10sve(svfloat32_t input)`) in `libvmath.so`. Without
>> this option, at build time, all the sve related featues like `arm_sve.h /
>> __ARM_FEATU
On Mon, 27 Nov 2023 01:06:21 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-vmath.m4 line 94:
>>
>>> 92: # Check the ARM SVE feature
>>> 93: SVE_CFLAGS="-march=armv8-a+sve"
>>> 94:
>>
>> What's this about? We're building a standard binary, and all SVE detection
>> is to be
On Thu, 23 Nov 2023 15:43:34 GMT, Andrew Haley wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments in build system
>
> make/autoconf/lib-vmath.m4 line 94:
>
>> 92: # Check the ARM SV
On Thu, 23 Nov 2023 14:10:02 GMT, Magnus Ihse Bursie wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments in build system
>
> make/autoconf/lib-vmath.m4 line 89:
>
>> 87: if test "x${LIBS
On Thu, 23 Nov 2023 08:57:23 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 X
On Thu, 23 Nov 2023 08:57:23 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 X
On Thu, 23 Nov 2023 08:57:23 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 X
On Thu, 23 Nov 2023 08:57:23 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 X
> 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
58 matches
Mail list logo
