On Tue, 8 Oct 2024 14:56:56 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Mon, 30 Sep 2024 10:33:20 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Thu, 26 Sep 2024 13:14:04 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Mon, 23 Sep 2024 16:25:02 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Mon, 23 Sep 2024 07:30:59 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Thu, 19 Sep 2024 08:32:38 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> Thanks!
>
> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
> the sleef source (in particular the generated sleef inline headers). We use
> sleef api to vectorize the ma
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, 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, 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 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, 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, 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 changes (renaming of c
On Mon, 26 Feb 2024 20:07:35 GMT, Magnus Ihse Bursie wrote:
>> I use `das` every day. In contrast, I don't know what `das1` is for.
>
> It does not sound like anyone object to the removal of `JNIEXPORT` for
> `das1`, then.
>
> Or should I just remove the entire function, if it serves no purpose
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, 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 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.
L
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
> lib
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
> lib
On Fri, 4 Aug 2023 09:10:48 GMT, Fei Yang wrote:
> Hello, did you check the license for libatomic.a? Is it compatible with
> libjvm.so?
When compiling with gcc or clang (which are AFAIK the only compiler supported
for Linux-RISC-V), it uses the compiler's implementation. In the case of GCC,
t
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 the
system where the Java application will run, which no other pl
On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev wrote:
> Fails like this:
>
>
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils
> --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
>
> === Output from failing command(s) repeated here ===
> * For target support_hs
On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev wrote:
> Fails like this:
>
>
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils
> --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
>
> === Output from failing command(s) repeated here ===
> * For target support_hs
On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev wrote:
> Fails like this:
>
>
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils
> --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
>
> === Output from failing command(s) repeated here ===
> * For target support_hs
On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev wrote:
> Fails like this:
>
>
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils
> --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
>
> === Output from failing command(s) repeated here ===
> * For target support_hs
On Fri, 21 Oct 2022 15:33:10 GMT, Aleksey Shipilev wrote:
>> Fails like this:
>>
>>
>> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils
>> --with-binutils-src=binutils-2.39
>> $ make clean build-hsdis
>>
>> === Output from failing command(s) repeated here ===
>> * For target s
On Thu, 13 Oct 2022 07:43:33 GMT, Ludovic Henry wrote:
> Currently, when passing --with-binutils-src, binutils is built in the source
> tree. That leads to conflicting targets when compiling for different
> architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target
est solution is to build binutils out-of-tree and into the
> build//binutils folder. These out-of-tree builds are already
> supported by binutils and only require some changes in the way we invoke the
> binutils/configure command.
Ludovic Henry has updated the pull request incrementally
On Mon, 17 Oct 2022 09:17:09 GMT, Magnus Ihse Bursie wrote:
>> Ludovic Henry 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 contain
On Thu, 13 Oct 2022 07:56:09 GMT, Aleksey Shipilev wrote:
>> Ludovic Henry 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 contain
est solution is to build binutils out-of-tree and into the
> build//binutils folder. These out-of-tree builds are already
> supported by binutils and only require some changes in the way we invoke the
> binutils/configure command.
Ludovic Henry has updated the pull request with a new tar
Currently, when passing --with-binutils-src, binutils is built in the source
tree. That leads to conflicting targets when compiling for different
architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target)
from the same jdk source tree.
The simplest solution is to build binutil
On Mon, 5 Sep 2022 13:22:03 GMT, Ludovic Henry wrote:
> It adds CI for cross-compiling to linux-riscv64. It requires to use Ubuntu
> repositories for the debootstrap image because Debian doesn't have riscv64
> packages on https://httpredir.debian.org/debian/. We can follow up on
On Mon, 5 Sep 2022 13:42:30 GMT, Ludovic Henry wrote:
>> It adds CI for cross-compiling to linux-riscv64. It requires to use Ubuntu
>> repositories for the debootstrap image because Debian doesn't have riscv64
>> packages on https://httpredir.debian.org/debian/. W
.com/ubuntu-ports for all
> cross-compiled architectures.
>
> This change also does not require nor blocks switching to Ubuntu 22.04.
>
> From talking with @shipilev, this replaces
> https://github.com/openjdk/jdk/pull/10086.
Ludovic Henry has updated the pull request increm
On Mon, 5 Sep 2022 19:05:04 GMT, Magnus Ihse Bursie wrote:
> (Also: what! Ubuntu has better platform support than Debian?!?)
I'm exploring using Debian ports repository, but it's not as straightforward as
I expected.
https://github.com/rivosinc/jdk/compare/dev/ludovic/ci-cross-compile-riscv64..
.com/ubuntu-ports for all
> cross-compiled architectures.
>
> This change also does not require nor blocks switching to Ubuntu 22.04.
>
> From talking with @shipilev, this replaces
> https://github.com/openjdk/jdk/pull/10086.
Ludovic Henry has updated the pull request with a n
It adds CI for cross-compiling to linux-riscv64. It requires to use Ubuntu
repositories for the debootstrap image because Debian doesn't have riscv64
packages on https://httpredir.debian.org/debian/. We can follow up on this
change with switching to http://ports.ubuntu.com/ubuntu-ports for all
38 matches
Mail list logo
