Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
On 12/09/2018 1:18 PM, Leslie Zhai wrote: Hi, Thanks for your kind response! 在 2018年09月12日 10:58, David Holmes 写道: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 Already known :) http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023181.html But I want to find out which commit or review bring in the "issue" in the LLVM side: http://lists.llvm.org/pipermail/llvm-dev/2018-September/125994.html Continue that discussion with the llvm folk but the OpenJDK part of this has been addressed. Cheers, David David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: RFR: JDK-8210519: build/releaseFile/CheckSource.java failed additional sources found
Looks okay to me too. Thanks, David On 12/09/2018 4:39 AM, Erik Joelsson wrote: Hello, I do agree with your points. http://cr.openjdk.java.net/~erikj/8210519/webrev.02/ On 2018-09-11 11:32, Mikael Vidstedt wrote: Looks good, thanks for fixing. Arguably the ":((hg)|(git)):[a-z0-9]*\\+?” string could be a constant (re-)used in the two places it occurs, and the nested if statements inside checking the Oracle specific part could be turned around to check "if (isOpenJDK)” first to avoid the negation, but that’s just my preference. Cheers, Mikael On Sep 10, 2018, at 3:09 PM, Erik Joelsson wrote: When I added support for git as SCM in the build, I forgot to update the test that verifies the release file contents. This patch updates the test to also look for hg/git in the SOURCE strings. While there I also made the test more strict on the format and less strict when run against non Oracle produced builds where we probably shouldn't be making assumptions on what extra repositories may be involved and included in the SOURCE line. Bug: https://bugs.openjdk.java.net/browse/JDK-8210519 Webrev: http://cr.openjdk.java.net/~erikj/8210519/webrev.01/ /Erik
Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
Hi Severin, Sorry I'm a bit confused now. Originally for ppc/s390x/aarch64 the optimization level for fdlibm was HIGH. But now it will be LOW due to: 45 ifneq ($(FDLIBM_CFLAGS), ) 46 BUILD_LIBFDLIBM_OPTIMIZATION := LOW as those platforms will use gcc/clang with support for -ffp-contract and so FDLIBM_CFLAGS will not be empty. ?? David On 12/09/2018 2:14 AM, Severin Gehwolf wrote: Hi Erik, Thanks for the review! On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote: Hello Severin, Even if using the macro, I still think you need to add a condition on the compiler types where the switch can be reasonably expected to exist. How about this? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/ Thanks, Severin On 2018-09-11 05:02, Severin Gehwolf wrote: On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote: I see. I was not aware of that issue, but we clearly need to file a bug for it and fix it. In this case I think it's fine to us the macro however. OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/ Micro-benchmark results from running [1] for x86_64 and ppc64le are here (-O2 is sufficient it seems): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/ More thoughts? Thanks, Severin [1] https://github.com/gromero/strictmath/
Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
Hi Severin, On 09/11/2018 09:02 AM, Severin Gehwolf wrote: Micro-benchmark results from running [1] for x86_64 and ppc64le are here (-O2 is sufficient it seems): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/ More thoughts? Thanks a lot for checking it on PPC64. I did additional tests on a POWER8 using the same microbench. I share the results below. The numbers are the arithmetic mean of 10 runs. Unit is second. 1 O3 | O2 2 MathStrictMath | MathStrictMath 3 | 4 acos:3.0728 3.0728 | acos:3.07325 3.07375 5 asin:3.0933 3.0916 | asin:3.09337 3.0915 6 atan2: 10.9743 10.9759 | atan2: 11.2994 11.2977 7 atan:7.653 7.6602 | atan:7.48463 7.48225 8 cbrt:13.444 13.4433 | cbrt:13.4535 13.4527 9 cos: 30.1561 33.9689 | cos: 30.157 35.1162 10 cosh:3.0911 3.1074 | cosh:3.09975 3.09088 11 exp: 1.413 3.0572 | exp: 1.41313 3.09737 12 expm1: 3.0281 3.0349 | expm1: 2.98813 2.98913 13 hypot: 33.7668 33.7471 | hypot: 27.9664 27.9675 14 log10: 4.2213 10.0832 | log10: 4.221 10.1109 15 log1p: 9.2886 9.2888 | log1p: 9.08713 9.08075 16 log: 3.1362 7.6327 | log: 3.136 7.633 17 pow: 13.7787 17.4739 | pow: 13.7829 17.483 18 sin: 30.216 33.9733 | sin: 30.2163 35.1684 19 sinh:3.1478 3.152 | sinh:3.18638 3.18375 20 sqrt:0.665 0.6714 | sqrt:0.665 0.671 21 tan: 31.6409 36.461 | tan: 31.6385 37.7166 22 tanh:3.0753 3.0925 | tanh:3.11088 3.10675 Based upon that, it looks like that O3 is better for most of the functions, specially for sin, cos, and tan. On the other hand, it looks like that O3 hurts hypot. Thus it seems -O2 is not quite the same as -O3, but it's not straightforward to decide which one is better too. Maybe Andrew can enlight us. I also CC:ed ppc-aix-port in case somebody there wishes to comment on that. Thank you. Best regards, Gustavo Thanks, Severin [1] https://github.com/gromero/strictmath/
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi, Thanks for your kind response! 在 2018年09月12日 10:58, David Holmes 写道: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 Already known :) http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023181.html But I want to find out which commit or review bring in the "issue" in the LLVM side: http://lists.llvm.org/pipermail/llvm-dev/2018-September/125994.html David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m -- Regards, Leslie Zhai
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: RFR: JDK-8210519: build/releaseFile/CheckSource.java failed additional sources found
Beautiful, thanks for fixing! Cheers, Mikael > On Sep 11, 2018, at 11:39 AM, Erik Joelsson wrote: > > Hello, > > I do agree with your points. > > http://cr.openjdk.java.net/~erikj/8210519/webrev.02/ > > > On 2018-09-11 11:32, Mikael Vidstedt wrote: >> Looks good, thanks for fixing. >> >> Arguably the ":((hg)|(git)):[a-z0-9]*\\+?” string could be a constant >> (re-)used in the two places it occurs, and the nested if statements inside >> checking the Oracle specific part could be turned around to check "if >> (isOpenJDK)” first to avoid the negation, but that’s just my preference. >> >> Cheers, >> Mikael >> >>> On Sep 10, 2018, at 3:09 PM, Erik Joelsson wrote: >>> >>> When I added support for git as SCM in the build, I forgot to update the >>> test that verifies the release file contents. This patch updates the test >>> to also look for hg/git in the SOURCE strings. While there I also made the >>> test more strict on the format and less strict when run against non Oracle >>> produced builds where we probably shouldn't be making assumptions on what >>> extra repositories may be involved and included in the SOURCE line. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210519 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8210519/webrev.01/ >>> >>> /Erik >>> >
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: RFR: JDK-8210519: build/releaseFile/CheckSource.java failed additional sources found
Hello, I do agree with your points. http://cr.openjdk.java.net/~erikj/8210519/webrev.02/ On 2018-09-11 11:32, Mikael Vidstedt wrote: Looks good, thanks for fixing. Arguably the ":((hg)|(git)):[a-z0-9]*\\+?” string could be a constant (re-)used in the two places it occurs, and the nested if statements inside checking the Oracle specific part could be turned around to check "if (isOpenJDK)” first to avoid the negation, but that’s just my preference. Cheers, Mikael On Sep 10, 2018, at 3:09 PM, Erik Joelsson wrote: When I added support for git as SCM in the build, I forgot to update the test that verifies the release file contents. This patch updates the test to also look for hg/git in the SOURCE strings. While there I also made the test more strict on the format and less strict when run against non Oracle produced builds where we probably shouldn't be making assumptions on what extra repositories may be involved and included in the SOURCE line. Bug: https://bugs.openjdk.java.net/browse/JDK-8210519 Webrev: http://cr.openjdk.java.net/~erikj/8210519/webrev.01/ /Erik
Re: RFR: JDK-8210519: build/releaseFile/CheckSource.java failed additional sources found
Looks good, thanks for fixing. Arguably the ":((hg)|(git)):[a-z0-9]*\\+?” string could be a constant (re-)used in the two places it occurs, and the nested if statements inside checking the Oracle specific part could be turned around to check "if (isOpenJDK)” first to avoid the negation, but that’s just my preference. Cheers, Mikael > On Sep 10, 2018, at 3:09 PM, Erik Joelsson wrote: > > When I added support for git as SCM in the build, I forgot to update the test > that verifies the release file contents. This patch updates the test to also > look for hg/git in the SOURCE strings. While there I also made the test more > strict on the format and less strict when run against non Oracle produced > builds where we probably shouldn't be making assumptions on what extra > repositories may be involved and included in the SOURCE line. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210519 > > Webrev: http://cr.openjdk.java.net/~erikj/8210519/webrev.01/ > > /Erik >
Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
Looks good, thanks! /Erik On 2018-09-11 09:14, Severin Gehwolf wrote: Hi Erik, Thanks for the review! On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote: Hello Severin, Even if using the macro, I still think you need to add a condition on the compiler types where the switch can be reasonably expected to exist. How about this? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/ Thanks, Severin On 2018-09-11 05:02, Severin Gehwolf wrote: On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote: I see. I was not aware of that issue, but we clearly need to file a bug for it and fix it. In this case I think it's fine to us the macro however. OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/ Micro-benchmark results from running [1] for x86_64 and ppc64le are here (-O2 is sufficient it seems): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/ More thoughts? Thanks, Severin [1] https://github.com/gromero/strictmath/
Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
Hi Erik, Thanks for the review! On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote: > Hello Severin, > > Even if using the macro, I still think you need to add a condition on > the compiler types where the switch can be reasonably expected to exist. How about this? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/ Thanks, Severin > On 2018-09-11 05:02, Severin Gehwolf wrote: > > On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote: > > > I see. I was not aware of that issue, but we clearly need to file a bug > > > for it and fix it. In this case I think it's fine to us the macro however. > > > > OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS. > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/ > > > > Micro-benchmark results from running [1] for x86_64 and ppc64le are > > here (-O2 is sufficient it seems): > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/ > > > > More thoughts? > > > > Thanks, > > Severin > > > > [1] https://github.com/gromero/strictmath/ > > > >
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi Dimitry, Thank you so much for the reduced testcase! It is able to reproduce after compiled with clang-8 optimized for X86: $ clang++ -O3 -S -c JDK-8205969.cpp -o JDK-8205969-opt-8.0.s $ clang++ -O3 -c JDK-8205969.cpp -o JDK-8205969-opt-8.0.o $ clang++ -o JDK-8205969-opt-8.0.out JDK-8205969-opt-8.0.o $ ./JDK-8205969-opt-8.0.out Segmentation fault $ cat JDK-8205969-opt-8.0.s .text .file "JDK-8205969.cpp" .globl main # -- Begin function main .p2align 4, 0x90 .type main,@function main: # @main .cfi_startproc # %bb.0: xorps %xmm0, %xmm0 movups %xmm0, _ZN15NativeCallStack11EMPTY_STACKE+16(%rip) movups %xmm0, _ZN15NativeCallStack11EMPTY_STACKE(%rip) xorl %eax, %eax retq .Lfunc_end0: .size main, .Lfunc_end0-main .cfi_endproc # -- End function .type _ZN15NativeCallStack11EMPTY_STACKE,@object # @_ZN15NativeCallStack11EMPTY_STACKE .section .rodata,"a",@progbits ^--- READ-ONLY segment .globl _ZN15NativeCallStack11EMPTY_STACKE .p2align 3 _ZN15NativeCallStack11EMPTY_STACKE: .zero 32 .size _ZN15NativeCallStack11EMPTY_STACKE, 32 .ident "LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 81ef98628ebf5186d746c0986dcbf5073e842043) (g...@github.com:llvm-mirror/llvm.git e1aac9723d55497e74d83d216329f08d9842e494) (based on LLVM 8.0.0svn)" .section ".note.GNU-stack","",@progbits .addrsig But it is *not* able to reproduce with clang-8 not optimized for X86: $ clang++ -O0 -S -c JDK-8205969.cpp -o JDK-8205969-unopt-8.0.s $ clang++ -O0 -c JDK-8205969.cpp -o JDK-8205969-unopt-8.0.o $ clang++ -o JDK-8205969-unopt-8.0.out JDK-8205969-unopt-8.0.o $ ./JDK-8205969-unopt-8.0.out No segfault $ cat JDK-8205969-unopt-8.0.s .text .file "JDK-8205969.cpp" .section .text.startup,"ax",@progbits .p2align 4, 0x90 # -- Begin function __cxx_global_var_init .type __cxx_global_var_init,@function __cxx_global_var_init: # @__cxx_global_var_init .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movabsq $_ZN15NativeCallStack11EMPTY_STACKE, %rdi callq _ZN15NativeCallStackC2Ev popq %rbp .cfi_def_cfa %rsp, 8 retq .Lfunc_end0: .size __cxx_global_var_init, .Lfunc_end0-__cxx_global_var_init .cfi_endproc # -- End function .section .text._ZN15NativeCallStackC2Ev,"axG",@progbits,_ZN15NativeCallStackC2Ev,comdat .weak _ZN15NativeCallStackC2Ev # -- Begin function _ZN15NativeCallStackC2Ev .p2align 4, 0x90 .type _ZN15NativeCallStackC2Ev,@function _ZN15NativeCallStackC2Ev: # @_ZN15NativeCallStackC2Ev .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movq %rdi, -8(%rbp) movq -8(%rbp), %rdi movl $0, -12(%rbp) movq %rdi, -24(%rbp) # 8-byte Spill .LBB1_1: # =>This Inner Loop Header: Depth=1 cmpl $4, -12(%rbp) jge .LBB1_4 # %bb.2: # in Loop: Header=BB1_1 Depth=1 movslq -12(%rbp), %rax movq -24(%rbp), %rcx # 8-byte Reload movq $0, (%rcx,%rax,8) # %bb.3: # in Loop: Header=BB1_1 Depth=1 movl -12(%rbp), %eax addl $1, %eax movl %eax, -12(%rbp) jmp .LBB1_1 .LBB1_4: popq %rbp .cfi_def_cfa %rsp, 8 retq .Lfunc_end1: .size _ZN15NativeCallStackC2Ev, .Lfunc_end1-_ZN15NativeCallStackC2Ev .cfi_endproc # -- End function .text .globl main # -- Begin function main .p2align 4, 0x90 .type main,@function main: # @main .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp subq $16, %rsp movl $0, -4(%rbp) movabsq $_ZN15NativeCallStack11EMPTY_STACKE, %rdi callq _ZN15NativeCallStackC2Ev xorl %eax, %eax addq $16, %rsp popq %rbp .cfi_def_cfa %rsp, 8 retq .Lfunc_end2: .size main, .Lfunc_end2-main .cfi_endproc # -- End function
Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
Hello Severin, Even if using the macro, I still think you need to add a condition on the compiler types where the switch can be reasonably expected to exist. /Erik On 2018-09-11 05:02, Severin Gehwolf wrote: On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote: I see. I was not aware of that issue, but we clearly need to file a bug for it and fix it. In this case I think it's fine to us the macro however. OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/ Micro-benchmark results from running [1] for x86_64 and ppc64le are here (-O2 is sufficient it seems): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/ More thoughts? Thanks, Severin [1] https://github.com/gromero/strictmath/
Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote: > I see. I was not aware of that issue, but we clearly need to file a bug > for it and fix it. In this case I think it's fine to us the macro however. OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/ Micro-benchmark results from running [1] for x86_64 and ppc64le are here (-O2 is sufficient it seems): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/ More thoughts? Thanks, Severin [1] https://github.com/gromero/strictmath/
