Re: [Patch v2] Enable math functions linking with static library for LTO

2019-08-22 Thread luoxhu
Hi Richard, On 2019/8/13 17:10, Richard Biener wrote: On Tue, Aug 13, 2019 at 4:22 AM luoxhu wrote: Hi Richard, On 2019/8/12 16:51, Richard Biener wrote: On Mon, Aug 12, 2019 at 8:50 AM luoxhu wrote: Hi Richard, Thanks for your comments, updated the v2 patch as below: 1. Define and use

Re: [PATCH] Add MD Function type check for builtin_md vectorize

2019-08-21 Thread luoxhu
On 2019/8/21 15:40, Richard Biener wrote: On Tue, 20 Aug 2019, Xiong Hu Luo wrote: The DECL_MD_FUNCTION_CODE added in r274404(PR 91421) by rsandifo requires that DECL to be a BUILTIN_IN_MD class built-in, asserts will happen when lto as the patch r274411(PR 91287) outputs some math function

Re: [Patch v2] Enable math functions linking with static library for LTO

2019-08-12 Thread luoxhu
On 2019/8/13 10:22, luoxhu wrote: diff --git a/gcc/testsuite/gcc.dg/pr91287.c b/gcc/testsuite/gcc.dg/pr91287.c new file mode 100644 index 000..c816e0537aa --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr91287.c @@ -0,0 +1,40 @@ +/* { dg-do assemble } */ +/* { dg-options "-O2"

Re: [Patch v2] Enable math functions linking with static library for LTO

2019-08-12 Thread luoxhu
Hi Richard, On 2019/8/12 16:51, Richard Biener wrote: On Mon, Aug 12, 2019 at 8:50 AM luoxhu wrote: Hi Richard, Thanks for your comments, updated the v2 patch as below: 1. Define and use builtin_with_linkage_p. 2. Add comments. 3. Add a testcase. In LTO mode, if static library and dynamic

[Patch v2] Enable math functions linking with static library for LTO

2019-08-12 Thread luoxhu
Hi Richard, Thanks for your comments, updated the v2 patch as below: 1. Define and use builtin_with_linkage_p. 2. Add comments. 3. Add a testcase. In LTO mode, if static library and dynamic library contains same function and both libraries are passed as arguments, linker will link the function in

[PATCH v3] Missed function specialization + partial devirtualization

2019-07-30 Thread luoxhu
This patch aims to fix PR69678 caused by PGO indirect call profiling performance issues. The bug that profiling data is never working was fixed by Martin's pull back of topN patches, performance got GEOMEAN ~1% improvement. Still, currently the default profile only generates SINGLE indirect target

Re: [PATCH v4] Generalize get_most_common_single_value to return k_th value & count

2019-07-17 Thread luoxhu
Hi Martin, On 2019/7/17 15:55, Martin Liška wrote: On 7/17/19 7:44 AM, luoxhu wrote: Hi Martin, Thanks for your review, v4 Changes as below: 1. Use decrease bubble sort. BTW, I have a question about hist->hvalue.counters[2], when will it become -1, please? Thanks. Currently, if it is

Re: [PATCH v4] Generalize get_most_common_single_value to return k_th value & count

2019-07-16 Thread luoxhu
Currently get_most_common_single_value could only return the max hist , add sort after reading from disk, then it return nth value in later use. Rename it to get_nth_most_common_value. Hi Martin, Thanks for your review, v4 Changes as below: 1. Use decrease bubble sort. BTW, I have a question

Re: [PATCH v3] Generalize get_most_common_single_value to return k_th value & count

2019-07-16 Thread luoxhu
Currently get_most_common_single_value could only return the max hist , add qsort to enable this function return nth value. Rename it to get_nth_most_common_value. v3 Changes: 1. Move sort to profile.c after loading values from disk. Simplify get_nth_most_common_value. 2. Make qsort

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-24 Thread luoxhu
On 2019/6/24 10:34, luoxhu wrote: Hi Honza, Thanks very much to get so many useful comments from you. As a newbie to GCC, not sure whether my questions are described clearly enough.  Thanks for your patience in advance.  :) On 2019/6/20 21:47, Jan Hubicka wrote: Hi, some comments

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-23 Thread luoxhu
Hi Honza, Thanks very much to get so many useful comments from you. As a newbie to GCC, not sure whether my questions are described clearly enough. Thanks for your patience in advance. :) On 2019/6/20 21:47, Jan Hubicka wrote: Hi, some comments on the ipa part of the patch (and thanks for

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-20 Thread luoxhu
Hi Martin, On 2019/6/20 09:59, luoxhu wrote: On 2019/6/19 20:18, Martin Liška wrote: On 6/19/19 10:56 AM, Martin Liška wrote: Thank you very much for the numbers. Today, I'm going to prepare the generalization of single-value counter to track N values. Ok, here's a patch candidate

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-19 Thread luoxhu
On 2019/6/19 20:18, Martin Liška wrote: On 6/19/19 10:56 AM, Martin Liška wrote: Thank you very much for the numbers. Today, I'm going to prepare the generalization of single-value counter to track N values. Ok, here's a patch candidate that does tracking of most common N values. For

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-19 Thread luoxhu
Hi Martin, On 2019/6/18 18:21, Martin Liška wrote: On 6/18/19 3:45 AM, Xiong Hu Luo wrote: 6.2. SPEC2017 peakrate: 523.xalancbmk_r (+4.87%); 538.imagick_r (+4.59%); 511.povray_r (+13.33%); 525.x264_r (-5.29%). Can you please elaborate what are the key indirect call

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-18 Thread luoxhu
Hi Martin, On 2019/6/18 17:34, Martin Liška wrote: On 6/18/19 11:02 AM, luoxhu wrote: Hi, On 2019/6/18 13:51, Martin Liška wrote: On 6/18/19 3:45 AM, Xiong Hu Luo wrote: Hello. Thank you for the interest in the area. This patch aims to fix PR69678 caused by PGO indirect call profiling

Re: [PATCH] [RFC, PGO+LTO] Missed function specialization + partial devirtualization

2019-06-18 Thread luoxhu
Hi, On 2019/6/18 13:51, Martin Liška wrote: On 6/18/19 3:45 AM, Xiong Hu Luo wrote: Hello. Thank you for the interest in the area. This patch aims to fix PR69678 caused by PGO indirect call profiling bugs. Currently the default instrument function can only find the indirect function that

Re: *Ping* Re: [PATCH] PR c/43673 - Incorrect warning in dfp printf.

2019-05-20 Thread luoxhu
Ping for GCC-10. Thanks Xionghu On 2019/3/4 09:13, Xiong Hu Luo wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01949.html Thanks Xionghu On 2019/2/26 AM9:13, luo...@linux.ibm.com wrote: From: Xiong Hu Luo dfp printf/scanf of Ha/HA, Da/DA and DDa/DDA is not set properly,

[PATCH] backport r257541, r259936, r260294, r260623, r261098, r261333, r268585.

2019-04-04 Thread luoxhu
From: Xiong Hu Luo These patches are followed changes for r25 on testcases vsx-vector-6*.c. backport them to update file names and fix regressions for GCC7 on power9. Regression tested on power7-be, power8-be, power8-le, power9. gcc/ChangeLog: 2019-04-03 Xiong Hu Luo backport

[PATCH] backport r268834 from mainline to gcc-7-branch

2019-03-05 Thread luoxhu
From: Xiong Hu Luo Backport r268834 of "Add support for the vec_sbox_be, vec_cipher_be etc." from mainline to gcc-8-branch. Regression-tested on Linux POWER8 LE. Backport patch for gcc-8-branch already got approved and commited. OK for gcc-7-branch? gcc/ChangeLog: 2019-03-05 Xiong Hu Luo

[PATCH v3] luoxhu - backport r250477, r255555, r257253 and r258137

2019-03-04 Thread luoxhu
From: Xiong Hu Luo This is a backport of r250477, r25, r257253 and r258137 from trunk to gcc-7-branch to support built-in functions: vec_extract_fp_from_shorth, vec_extract_fp_from_shortl, vec_extract_fp32_from_shorth and vec_extract_fp32_from_shortl, etc. The patches were on trunk before

[PATCH] PR c/43673 - Incorrect warning in dfp printf.

2019-02-25 Thread luoxhu
From: Xiong Hu Luo dfp printf/scanf of Ha/HA, Da/DA and DDa/DDA is not set properly, cause incorrect warning happens: "use of 'D' length modifier with 'a' type character". Regression-tested on powerpc64le-linux, OK for trunk and gcc-8? gcc/c-family/ChangeLog: 2019-02-25 Xiong Hu Luo

[PATCH] luoxhu - backport from trunk r255555, r257253 and r258137

2019-02-18 Thread luoxhu
From: Xiong Hu Luo This is a backport of r25, r257253 and r258137 of trunk to gcc-7-branch. The patches were on trunk before GCC 8 forked already. Totally 5 files need mannual resolve due to code changes for r25. r257253 and r258137 are dependent testcases require vsx support need merge

[PATCH 2/2] fix comments typo.

2019-01-23 Thread luoxhu
From: Xiong Hu Luo commited in 268229. --- gcc/ChangeLog 2019-01-24 Xiong Hu Luo * tree-ssa-dom.c (test_for_singularity): fix a comment typo. * vr-values.c (find_case_label_ranges): fix a comment typo. --- gcc/tree-ssa-dom.c | 2 +- gcc/vr-values.c| 2 +- 2 files

[PATCH 1/2] fix tab alignment issue.

2019-01-23 Thread luoxhu
From: Xiong Hu Luo commited in r268228. --- ChangeLog 2019-01-24 Xiong Hu Luo * ChangeLog: replace space with tab. * MAINTAINERS: delete 1 tab to keep alignment. --- ChangeLog | 4 ++-- MAINTAINERS | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff

[PATCH] rs6000: Add support for the vec_sbox_be, vec_cipher_be etc. builtins.

2019-01-23 Thread luoxhu
From: Xiong Hu Luo The 5 new builtins vec_sbox_be, vec_cipher_be, vec_cipherlast_be, vec_ncipher_be and vec_ncipherlast_be only support vector unsigned char type parameters. Add new instruction crypto_vsbox_ and crypto__ to handle them accordingly, where the new mode CR_vqdi can be expanded to

[PATCH] luoxhu - backport from trunk r255555:

2019-01-22 Thread luoxhu
From: carll backport from trunk to gcc-7-branch. gcc/ChangeLog: 2017-12-11 Carl Love * config/rs6000/altivec.h (vec_extract_fp32_from_shorth, vec_extract_fp32_from_shortl]): Add #defines. * config/rs6000/rs6000-builtin.def (VSLDOI_2DI): Add macro expansion.

<    1   2