[PATCH V5 2/2] rs6000: use mtvsrws to move sf from si p9

; xscvspdpn 1,1". Compare with previous patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628791.html According to review comments, this version refines commit message and words in comments, also updates the test case Pass bootstrap and regtest on ppc64{,le}. Is this ok for trunk?

[PATCH V5 1/2] rs6000: optimize moving to sf from highpart di

gtest on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/108338 gcc/ChangeLog: * config/rs6000/predicates.md (lowpart_subreg_operator): New define_predicate. * config/rs6000/rs6000.md (any_rshift): New code_iterator. (movsf_from_si2): Ren

Re: [PATCH V5 2/2] rs6000: use mtvsrws to move sf from si p9

Hi, David Edelsohn writes: > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > > On Thu, Oct 5, 2023 at 12:14 AM Jiufu Guo wrote: > > Hi, > > As mentioned in PR108338, on p9, we could use

Re: [PATCH V5 1/2] rs6000: optimize moving to sf from highpart di

Hi, David Edelsohn writes: > > On Thu, Oct 5, 2023 at 12:50 AM Jiufu Guo wrote: > > Hi, > > Currently, we have the pattern "movsf_from_si2" which was trying > to support moving high part DI to SF. > > But current pattern only accepts "ashiftrt

[PATCH V1] introduce light expander sra

id to store the parameter to stack if it is scalarized. https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631177.html This patch is tested on ppc64{,le} and x86_64. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/65421 gcc/ChangeLog: * cfgexpand.cc (struct a

[PATCH] use get_range_query to replace get_global_range_query

deoes not draft new test cases). Pass bootstrap & regtest on ppc64{,le} and x86_64. Is this ok for trunk. BR, Jeff (Jiufu Guo) gcc/ChangeLog: * builtins.cc (expand_builtin_strnlen): Replace get_global_range_query by get_range_query. * fold-const.cc (expr_not_equal_to):

Re: [PATCH] use get_range_query to replace get_global_range_query

Hi, Richard Biener writes: > On Tue, 10 Oct 2023, Jiufu Guo wrote: > >> Hi, >> >> For "get_global_range_query" SSA_NAME_RANGE_INFO can be queried. >> For "get_range_query", it could get more context-aware range info. >> And look

[PATCH V1] use more get_range_query

/2023-October/632401.html This patch remove some unsafe replacement. Pass bootstrap & regtest on ppc64{,le} and x86_64. Is this ok for trunk. BR, Jeff (Jiufu Guo) gcc/ChangeLog: * fold-const.cc (expr_not_equal_to): Replace get_global_range_query by get_range_query. * g

[PATCH] early outs for functions in rs6000.cc

refined. And similar code are also restuctured in rs6000.cc. This patch pass bootstrap and regtest on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/rs6000/rs6000.cc (vspltis_shifted): Adopt early outs. (rs6000_cost_data

Re: [PATCH] early outs for functions in rs6000.cc

Hi, David Edelsohn writes: > > On Tue, Oct 10, 2023 at 9:29 PM Jiufu Guo wrote: > > Hi, > > There are some piece of code like below in rs6000.cc: > > ... > if (xx) > return x; > else if (yy) > return y; > ... //else if chain >

Re: [PATCH] PR target/111778 - Fix undefined shifts in PowerPC compiler

gt;/* Get the position for the first bit of successive 1. > The 24th bit would be in successive 0 or 1. */ > - HOST_WIDE_INT low_mask = (1LL << 24) - 1LL; > + HOST_WIDE_INT low_mask = (HOST_WIDE_INT_1U << 24) - HOST_WIDE_INT_1U; Yes. >int pos_first_1 = ((c & (low_mask + 1)) == 0) > ? clz_hwi (c & low_mask) > : HOST_BITS_PER_WIDE_INT - ctz_hwi (~(c | low_mask)); > + > + /* Make sure the left and right shifts are defined. */ > + if (!IN_RANGE (pos_first_1, 1, HOST_BITS_PER_WIDE_INT-1)) > +return false; > + Yes, this change would be safer. Thanks again for the enhancement! BR, Jeff (Jiufu Guo) >middle_ones = clz_hwi (~c << pos_first_1); >middle_zeros = ctz_hwi (c >> (HOST_BITS_PER_WIDE_INT - pos_first_1)); >if (pos_first_1 < HOST_BITS_PER_WIDE_INT > -- > 2.41.0

Re: [PATCH V1] use more get_range_query

Hi, Richard Biener writes: > On Wed, 11 Oct 2023, Jiufu Guo wrote: > >> Hi, >> >> For "get_global_range_query" SSA_NAME_RANGE_INFO can be queried. >> For "get_range_query", it could get more context-aware range info. >> And look

[PATCH 1/3]rs6000: update num_insns_constant for 2 insns

Hi, Trunk gcc supports more constants to be built via two instructions: e.g. "li/lis; xori/xoris/rldicl/rldicr/rldic". And then num_insns_constant should also be updated. Bootstrap & regtest pass ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: *

[PATCH 2/3]rs6000: using 'pli' to load 34bit-constant

Hi, For constants with 16bit values, 'li or lis' can be used to generate the value. For 34bit constant, 'pli' is ok to generate the value. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * con

[PATCH 3/3]rs6000: split complicate constant to constant pool

about ~1.8% (-O2) when support loading complicates constant from constant pool. And no visible performance recession on other benchmarks. Boostrap & regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/63281 gcc/ChangeLog: * config/rs6000/rs600

Re: [PATCH 1/3]rs6000: update num_insns_constant for 2 insns

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/10/25 10:00, Jiufu Guo wrote: >> Hi, >> >> Trunk gcc supports more constants to be built via two instructions: e.g. >> "li/lis; xori/xoris/rldicl/rldicr/rldic". >> And then num_insns_consta

Re: [PATCH 2/3]rs6000: using 'pli' to load 34bit-constant

Hi, "Kewen.Lin" writes: > on 2023/10/25 10:00, Jiufu Guo wrote: >> Hi, >> >> For constants with 16bit values, 'li or lis' can be used to generate >> the value. For 34bit constant, 'pli' is ok to generate the value. >> >>

Re: [PATCH 3/3]rs6000: split complicate constant to constant pool

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/10/25 10:00, Jiufu Guo wrote: >> Hi, >> >> Sometimes, a complicated constant is built via 3(or more) >> instructions to build. Generally speaking, it would not be >> as faster as loading it from the

Re: [PATCH 3/3]rs6000: split complicate constant to constant pool

Hi, "Kewen.Lin" writes: > on 2023/10/25 16:14, Jiufu Guo wrote: >> >> Hi, >> >> "Kewen.Lin" writes: >> >>> Hi, >>> >>> on 2023/10/25 10:00, Jiufu Guo wrote: >>>> Hi, >>>> >>&

[PATCH V2] introduce light expander sra

be removed. e.g. address-taken and accessed via memory. "foo(struct S arg) {bar (&arg);}" This patch is tested on ppc64{,le} and x86_64. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/65421 gcc/ChangeLog: * cfgexpand.cc (struct access): Ne

[PATCH] rs6000, testcase: Add require-effective-target has_arch_ppc64 to pr106550_1.c

Hi, With latest trunk, case pr106550_1.c can run with failure on ppc under -m32. While, the case is testing 64bit constant building. So, "has_arch_ppc64" is required. Test pass on ppc64{,le}. BR, Jeff (Jiufu Guo) gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr10655

[PATCH] rs6000: Enable limited unrolling at -O2

S=2 and PARAM_MAX_UNROLLED_INSNS=20, we can see >2% overall improvement for SPEC2017. This patch is only for rs6000 in which we see visible performance improvement. Bootstrapped on powerpc64le, and cases are updated. Is this ok for trunk? Jiufu Guo BR gcc/ 2019-10-25 Jiufu Guo

Re: [PATCH] rs6000: Enable limited unrolling at -O2

Richard Biener writes: > On Fri, 25 Oct 2019, Jiufu Guo wrote: > >> Hi, >> >> In PR88760, there are a few disscussion about improve or tune unroller for >> targets. And we would agree to enable unroller for small loops at O2 first. >> And we could see per

[PATCH] rs6000: Refine implicit funroll-loops with unroll_adjust hook.

unroll adjust hook for rs6000 to impliment previous behavior. Bootstrapped and regtested on powerpc64le. Is this ok for trunk? A combined patch is listed at the end of this mail for this and r277501. If you want to review it as a whole, it can be referenced. Jiufu Guo BR gcc/ 2019-10-29 Jiufu

Re: [PATCH] rs6000: Refine implicit funroll-loops with unroll_adjust hook.

Jiufu Guo writes: > Hi, > > In previous patch r277501, which is changing PARAM_MAX_UNROLL_TIMES > and PARAM_MAX_UNROLLED_INSNS values during option overriding, while > it would better to use target loop unroll adjust hook. The hook can > also help to do further target relate

Re: [PATCH] rs6000: Enable limited unrolling at -O2

Richard Biener writes: > On Mon, 28 Oct 2019, Jiufu Guo wrote: > >> Richard Biener writes: >> >> > On Fri, 25 Oct 2019, Jiufu Guo wrote: >> > >> >> Hi, >> >> >> >> In PR88760, there are a few disscussion about improve o

Re: [PATCH] rs6000: Refine implicit funroll-loops with unroll_adjust hook.

Richard Biener writes: > On Tue, 29 Oct 2019, Jiufu Guo wrote: > >> Jiufu Guo writes: >> >> > Hi, >> > >> > In previous patch r277501, which is changing PARAM_MAX_UNROLL_TIMES >> > and PARAM_MAX_UNROLLED_INSNS values during option ove

Re: [PATCH] rs6000: Refine implicit funroll-loops with unroll_adjust hook.

Richard Biener writes: > On Tue, 29 Oct 2019, Jiufu Guo wrote: > >> For this patch at -flto, loop-unrolling is affected by command line >> besides optimize level per function. >> -flto -c t.c -O2 -funroll-loops >> -flto t.o -O2 or -flto t.o, >> this lin

[PATCH V2] rs6000: Refine unroll factor with target unroll_adjust hook.

regtested on powerpc64le. Is this ok for trunk? Jiufu BR. gcc/ 2019-10-30 Jiufu Guo PR tree-optimization/88760 * config/rs6000/rs6000.c (rs6000_option_override_internal): Remove code which changes PARAM_MAX_UNROLL_TIMES and PARAM_MAX_UNROLLED_INSNS

Re: [PATCH V2] rs6000: Refine unroll factor with target unroll_adjust hook.

Segher Boessenkool writes: > Hi! > > On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote: >> In this patch, loop unroll adjust hook is introduced for powerpc. In this >> hook, >> we can do target related hueristic adjustment. For this patch, we tunned for >&

[PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

[Patch V2] to enable small loops unroll for O3 by default like O2. Bootstrapped and regtested on powerpc64le. Is this ok for trunk? Jiufu BR. gcc/ 2019-11-04 Jiufu Guo PR tree-optimization/88760 * config/rs6000/rs6000.c (rs6000_option_override_internal): Remove

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

"Kewen.Lin" writes: > Hi Jeff, > > Thanks for the patch, I learned a lot from it. Some nits embedded. Thanks for your comments! > > on 2019/11/4 下午2:31, Jiufu Guo wrote: >> Hi, >> >> In this patch, loop unroll adjust hook is introduced for powe

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Segher Boessenkool writes: > Hi! > > On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >> In this patch, loop unroll adjust hook is introduced for powerpc. We can do >> target related hueristic adjustment in this hook. In this patch, small loops >> is unroll

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Richard Biener writes: > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > >> Hi! >> >> On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >> > In this patch, loop unroll adjust hook is introduced for powerpc. We can >> > do >> > target

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: > Segher Boessenkool writes: > >> Hi! >> >> On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >>> In this patch, loop unroll adjust hook is introduced for powerpc. We can do >>> target related hueristic adjustment in th

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: Got message about fail to send to gcc-patches. Send again. > Segher Boessenkool writes: > >> Hi! >> >> On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >>> In this patch, loop unroll adjust hook is introduced for powerpc. We ca

[PATCH V4] rs6000: Refine unroll factor in loop_unroll_adjust hook

. Based on [PATCH V3], this patch enhanced a little by adding an option -munroll-small-loops to guard the small loops unrolling to make it works fine with -flto. Successfully bootstrapped and regtested on powerpc64le. OK for trunk? Jiufu Guo BR. gcc/ 2019-11-06 Jiufu Guo PR tree

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Segher Boessenkool writes: > Hi! > > On Tue, Nov 05, 2019 at 04:33:23PM +0800, Jiufu Guo wrote: >> --- gcc/common/config/rs6000/rs6000-common.c (revision 277765) >> +++ gcc/common/config/rs6000/rs6000-common.c (working copy) >> @@ -35,7 +35,9 @@ static const struct def

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: > Segher Boessenkool writes: > >> Hi! >> >> On Tue, Nov 05, 2019 at 04:33:23PM +0800, Jiufu Guo wrote: >>> --- gcc/common/config/rs6000/rs6000-common.c(revision 277765) >>> +++ gcc/common/config/rs6000/rs6000-common.c(

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: Hi Segher, I updated the patch for option name at the end of this mail. Thanks for review in advance. > Jiufu Guo writes: > >> Segher Boessenkool writes: >> >>> Hi! >>> >>> On Tue, Nov 05, 2019 at 04:33:23PM +0800, Jiufu Guo wr

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: Hi Sehger, I updated the patch as we discussed. This patch does not turn on -fweb or -frename-registers with -funroll-loops for powerpc. Thanks for review in advance. gcc/ 2019-11-07 Jiufu Guo PR tree-optimization/88760 * gcc/config/rs6000/rs6000.opt

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Segher Boessenkool writes: > Hi Jiu Fu, > > On Thu, Nov 07, 2019 at 10:40:41PM +0800, Jiufu Guo wrote: >> gcc/ >> 2019-11-07 Jiufu Guo >> >> PR tree-optimization/88760 >> * gcc/config/rs6000/rs6000.opt (-munroll-only-small-loops): New opt

[PATCH] correct COUNT and PROB for unrolled loop

sions. And spec2017 result is fine: a couple INT benchmarks that showed around 1.7% improvement, everything else was +/- <= 1%. Ok for trunk? Jiufu Guo 2020-02-03 Jiufu Guo Pat Haugen PR rtl-optimization/68212 * cfgloopmanip.c (duplicate_loop_to_header_edge):

[PATCH, rs6000]: mark clobber for registers changed by untpyed_call

changed by untyped call. Because this would be a kind of wrong code, so I'm thinking to submit to gcc10. Bootstrap and regtest on powerpc64le are pass. Is this okay for trunk? Thanks, Jiufu gcc/ 2020-02-05 Jiufu Guo PR target/93047 * config/rs6000/rs6000.md (untyped_call)

Re: [PATCH, rs6000]: mark clobber for registers changed by untpyed_call

Segher Boessenkool writes: > On Wed, Feb 05, 2020 at 09:53:27PM +0800, Jiufu Guo wrote: >> As PR93047 said, __builtin_apply/__builtin_return does not work well with >> -frename-registers. This is caused by return register(e.g. r3) is used to >> rename another register, befo

Re: [PATCH, rs6000]: mark clobber for registers changed by untpyed_call

Segher Boessenkool writes: > Hi! > > On Thu, Feb 06, 2020 at 10:49:36AM +0800, Jiufu Guo wrote: >> > emit_call_insn (gen_call (operands[0], const0_rtx, const0_rtx)); >> > >> > for (i = 0; i < XVECLEN (operands[2], 0); i++) >> > {

Re: [PATCH 1/4 v2 GCC11] Add middle-end unroll factor estimation

"Kewen.Lin" writes: > Hi Segher, > > Thanks for your comments! Updated to v2 as below: > > 1) Removed unnecessary hook loop_unroll_adjust_tree. > 2) Updated estimated_uf to estimated_unroll and some comments. > > gcc/ChangeLog > > 2020-02-10 Kewen Lin > > * cfgloop.h (struct loop):

Re: [PATCH] correct COUNT and PROB for unrolled loop

Jan Hubicka writes: >> On Mon, 2020-02-03 at 10:04 -0600, Pat Haugen wrote: >> > On 2/3/20 2:17 AM, Jiufu Guo wrote: >> > > +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 937042044" 1 >> > > "loop2_unroll"} } */ >> &g

Re: [PATCH, rs6000]: mark clobber for registers changed by untpyed_call

Segher Boessenkool writes: > On Sat, Feb 08, 2020 at 10:17:42AM -0600, Segher Boessenkool wrote: >> And we do not know which of the register will be used for the return, in >> untyped_call (only untyped-return knows). But we can add clobbers of all >> registers that *might* be used for the retur

Re: [PATCH V2] correct COUNT and PROB for unrolled loop

Hi Honza and all, I updated the patch a little as below. Bootstrap and regtest are ok on powerpc64le. Is OK for trunk? Thanks for comments. Jiufu diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c index 727e951..ded0046 100644 --- a/gcc/cfgloopmanip.c +++ b/gcc/cfgloopmanip.c @@ -31,6 +31,7

Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus

Li Jia He writes: > Hi, > @@ -546,6 +546,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (simplify >(mod (mod@2 @0 @1) @1) >@2) > + /* Optimize (x shift (n mod C)) to (x shift (n bit_and (C - 1))) when C is a > +constant and power of two. */ > + (for shift (lshift rshift) > + (simpli

[PATCH] enable -fweb and -frename-registers at -O3 for rs6000

. This patch enable -fweb and -frename-registers for -O3 to align original behavior before r278034. Since this patch help to prevent performance regression, I'm thinking to submit to trunk. Bootstrap and regtest pass on powerpc64le. Is this okay for trunk? Thanks, Jiufu gcc/ 2019-12-20 Jiuf

Re: [PATCH] enable -fweb and -frename-registers at -O3 for rs6000

Segher Boessenkool writes: > Hi! > > On Fri, Dec 20, 2019 at 02:34:05PM +0800, Jiufu Guo wrote: >> Previously, limited unrolling was enabled at O2 for powerpc in r278034. At >> that >> time, -fweb and -frename-registers were not enabled together with >> -funr

[PATCH V2]rs6000: re-enable web and rnreg with -funroll-loops

Jiufu Guo writes: > Segher Boessenkool writes: > >> Hi! >> >> On Fri, Dec 20, 2019 at 02:34:05PM +0800, Jiufu Guo wrote: >>> Previously, limited unrolling was enabled at O2 for powerpc in r278034. At >>> that >>> time, -fweb and -frename-reg

Re: [PATCH] enable -fweb and -frename-registers at -O3 for rs6000

Jiufu Guo writes: > Segher Boessenkool writes: > >> Hi! >> [...] >>> --- a/gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c >>> +++ b/gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c >>> @@ -2,6 +2,7 @@ >>>

[PATCH v2, RFC] fsra: gimple final sra pass for paramters and returns

access * Parameter access cross call * Optimize for access parameter which in memory * More cases/targets checking I would like to ask for comments to avoid major flaw. BR, Jeff (Jiufu Guo) PR target/108073 PR target/65421 PR target/69143 gcc/ChangeLog

[PATCH] s390: avoid peeking eof after __vector

Hi, Same like PR101168, this patch is need for s390 to avoid peeking eof after vector keyword. And similar test case is also ok for s390. Is this ok for trunk? Jeff (Jiufu Guo) PR target/95782 gcc/ChangeLog: * config/s390/s390-c.cc (s390_macro_to_expand): Avoid empty

[PATCH 1/3, RFC] fsra: Add final gimple sra just before expander

This patch adds a new mode for sra pass: "fsra". This 'fsra' pass handle function parameters and returns as candidates. And run it at the end of GIMPLE passes sequences. gcc/ChangeLog: * passes.def: Add pass pass_sra_final. * tree-pass.h (make_pass_sra_final): Declare make_pass_sr

[PATCH 3/3, RFC] fsra: support SET_RET_PART

This patch adds IFN_SET_RET_PARTS, and generate this IFN for the accesses of the 'returns' in fsra pass. And the IFN is expanded according to the outgoing registers of the 'return'. "fsra" is tunned for the access analyze for 'returns'. 'IFN_SET_RET_LAST_PARTS' is just for this prototype, it hel

[PATCH 0/3, RFC] fsra: Add final gimple sra before expander

ing and make the dumped rtl is a little confused. Any comments? This prototype is splitted into three patches for review. 1/3: Add final gimple sra just before expander 2/3: Add support for ARG_PARTS 3/3: Add support for RET_PARTS Thanks for your comments and suggestions! BR, Jeff (Jiufu Guo)

[PATCH 2/3, RFC] fsra: support ARG_PARTS

This patch adds IFN_ARG_PARTS, and generate this IFN for parameters access in fsra pass. And this IFN is expanded according to the incoming registers of the parameter. "fsra" is tunned for the access of parameters. PR target/108073 gcc/ChangeLog: * internal-fn.cc (query_positio

[PATCH V3 1/3]rs6000: update num_insns_constant for 2 insns

t them together to avoid misalign in the future. Bootstrap & regtest pass ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Add new parameter to record number of instructions to build the co

[PATCH V3 2/3] Using pli for constant splitting

,3,32,0" can be used. Compare with previous: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636567.html This verion is refreshed and added with a new testcase. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/rs6000/rs6000

[PATCH V3 3/3] split complicate constant to memory

//gcc.gnu.org/pipermail/gcc-patches/2023-November/636566.html This version is refreshed based on the latest code. Boostrap & regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/63281 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_c

[PATCH] treat argp-based mem as frame related in dse

. Bootstrap ®test pass on ppc64{,le} and x86_64. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR rtl-optimization/112525 gcc/ChangeLog: * dse.cc (get_group_info): Add arg_pointer_rtx as frame_related. (check_mem_read_rtx): Add parameter to indicate if it is checking mem

Re: [PATCH V3 1/3]rs6000: update num_insns_constant for 2 insns

Hi, Thanks for your always kind and helpful review!! "Kewen.Lin" writes: > Hi Jeff, > > on 2023/12/6 13:24, Jiufu Guo wrote: >> Hi, >> >> Trunk gcc supports more constants to be built via two instructions: >> e.g. "li/lis; xori/xoris/rldi

Re: [PATCH V3 2/3] Using pli for constant splitting

Hi, Thanks for your insight and helpful review! "Kewen.Lin" writes: > Hi Jeff, > > on 2023/12/6 13:24, Jiufu Guo wrote: >> Hi, >> >> For constant building e.g. r120=0x, which does not fit 'li or lis', >> 'pli' is used

Re: [PATCH] treat argp-based mem as frame related in dse

Hi, Jeff Law writes: > On 12/6/23 02:27, Jiufu Guo wrote: >> Hi, >> >> The issue mentioned in PR112525 would be able to be handled by >> updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx. >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id

Re: [PATCH] treat argp-based mem as frame related in dse

Hi, Thanks again for your kind review! Jeff Law writes: > On 12/8/23 00:18, Jiufu Guo wrote: >> >> Hi, >> >> Jeff Law writes: >> >>> On 12/6/23 02:27, Jiufu Guo wrote: >>>> Hi, >>>> >>>> The issue ment

[PATCH V4 1/3]rs6000: accurate num_insns_constant_gpr

not emit instructions). Compare with the previous version, https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639491.html this version updates a lambda usage and comments. Bootstrap & regtest pass ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/

[PATCH V4 2/3] Using pli for constant splitting

,3,32,0" can be used. Compare with previous: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639492.html This verion is refreshed and updated testcase name. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/rs6000/rs6000

Re: [PATCH] treat argp-based mem as frame related in dse

Hi, Thanks for your quick reply! Jeff Law writes: > On 12/10/23 20:07, Jiufu Guo wrote: > >>>>> I'm having a bit of a hard time convincing myself this is correct >>>>> though. I can't see how rewriting the load to read the source of the >>

Re: [PATCH V4 2/3] Using pli for constant splitting

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/12/11 11:26, Jiufu Guo wrote: >> Hi, >> >> For constant building e.g. r120=0x, which does not fit 'li or lis', >> 'pli' is used to build this constant via 'emit_move_insn&#

Re: [PATCH V4 1/3]rs6000: accurate num_insns_constant_gpr

Hi, "Kewen.Lin" writes: > Hi Jeff, > > on 2023/12/11 11:26, Jiufu Guo wrote: >> Hi, >> >> Trunk gcc supports more constants to be built via two instructions: >> e.g. "li/lis; xori/xoris/rldicl/rldicr/rldic". >> And then

Re: [PATCH] rs6000, testcase: Add require-effective-target has_arch_ppc64 to pr106550_1.c

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/11/6 15:20, Jiufu Guo wrote: >> Hi, >> >> With latest trunk, case pr106550_1.c can run with failure on ppc under -m32. >> While, the case is testing 64bit constant building. So, "has_arch_ppc64" &

[PATCH V2 1/3]rs6000: update num_insns_constant for 2 insns

structions). Compare with previous verions: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634195.html This verion adds an argument to "rs6000_emit_set_long_const" to indicate computing instruction number instead emit intructions. Bootstrap & regtest pass ppc64{,le}. Is this ok fo

[PATCH V2 3/3] split complicate constant to memory

c.gnu.org/pipermail/gcc-patches/2023-October/634197.html This verion updates commit message. Boostrap & regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/63281 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_const): Update to

[PATCH V2 2/3] Using pli to split 34bits constant

org/pipermail/gcc-patches/2023-October/634196.html This verion updates a testcase to cover this functionality. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Add code to use

Ping: [PATCH V2] introduce light expander sra

the comments in advance. BR, Jeff (Jiufu Guo) Jiufu Guo writes: > Hi, > > Compare with previous version: > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632399.html > This verion supports TI/VEC mode of the access. > > There are a few PRs (meta-bug PR101926) on v

Re: [PATCH V2 2/3] Using pli to split 34bits constant

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/11/15 11:02, Jiufu Guo wrote: >> Hi, >> >> For constants with 16bit values, 'li or lis' can be used to generate >> the value. For 34bit constant, 'pli' is ok to generate the value. &

Re: [PATCH V2 1/3]rs6000: update num_insns_constant for 2 insns

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/11/15 11:02, Jiufu Guo wrote: >> Hi, >> >> Trunk gcc supports more constants to be built via two instructions: e.g. >> "li/lis; xori/xoris/rldicl/rldicr/rldic". >> And then

Re: [PATCH V2] introduce light expander sra

Hi, Thanks so much for your helpful review! Richard Biener writes: > On Fri, Oct 27, 2023 at 3:51 AM Jiufu Guo wrote: >> >> Hi, >> >> Compare with previous version: >> https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632399.html >> This ve

[PATCH] check undefine_p for one more vr

s undefined_p is not checked before "wi::geu_p (vr0.lower_bound (), -c)". Bootstrap & regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR tree-optimization/111355 gcc/ChangeLog: * match.pd ((X + C) / N): Update pattern. gcc/testsuite/ChangeLo

Re: [PATCH 1/2] using overflow_free_p to simplify pattern

Hi, Richard Biener writes: > On Tue, 19 Sep 2023, Jiufu Guo wrote: > >> Hi, >> >> In r14-3582, an "overflow_free_p" interface is added. >> The pattern of "(t * 2) / 2" in match.pd can be simplified >> by using this interface. >>

Re: [PATCH] check undefine_p for one more vr

Hi, Richard Biener writes: >> Am 21.09.2023 um 05:10 schrieb Jiufu Guo : >> >> Hi, >> >> The root cause of PR111355 and PR111482 is missing to check if vr0 >> is undefined_p before call vr0.lower_bound. >> >> In the pattern &qu

[PATCH] light expander sra

capability to go through functions and check interesting sra stmts. - We can continue refactoring the code to share similar frameworks even if the behaviors are slightly different between those SRAs. This patch is tested on ppc64{,le}. Thanks a lot for your review in advance? BR, Jeff (Jiufu Guo)

Ping^2 [PATCH V5 1/4] rs6000: build constant via li;rotldi

Hi, Gentle ping... BR, Jeff (Jiufu Guo) Jiufu Guo via Gcc-patches writes: > Hi, > > Gentle ping... > > BR, > Jeff (Jiufu Guo) > > Jiufu Guo writes: > >> Hi, >> >> If a constant is possible to be rotated to/from a positive or negative >> valu

Re: [PATCH] Checking undefined_p before using the vr

Hi Andrew, Thanks for your explain! And sorry for later reply. Andrew MacLeod writes: > On 9/14/23 22:07, Jiufu Guo wrote: >>> >>> undefined is a perfectly acceptable range.  It can be used to >>> represent either values which has not been initialized, or mor

Re: [PATCH V4 1/2] rs6000: optimize moving to sf from highpart di

Hi, "Kewen.Lin" writes: > Hi Jeff, > > on 2023/8/30 15:43, Jiufu Guo wrote: >> Hi, >> >> Currently, we have the pattern "movsf_from_si2" which was trying >> to support moving high part DI to SF. >> >> The pattern looks l

Re: [PATCH V4 2/2] rs6000: use mtvsrws to move sf from si p9

Hi, "Kewen.Lin" writes: > Hi Jeff, > > on 2023/8/30 15:43, Jiufu Guo wrote: >> Hi, >> >> As mentioned in PR108338, on p9, we could use mtvsrws to implement >> the bitcast from SI to SF (or lowpart DI to SF). >> >> For code: >

[PATCH V6 1/2] split complicate 64bit constant to memory

eter to control how complicate constant should be put into the constant pool. 2. updated test cases, and to keep the orignal test point. Boostrap & regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/63281 gcc/ChangeLog: * config/rs6000/rs6000

[PATCH V6 2/2] split complicate 64bit constant to memory for -m32 -mpowerpc64

ntrol what kind of complicate constanst should be put into memory. Bootstrap and regtest pass on ppc64{,le}. Also no regression for "-m32 -mpowerpc64" variation on ppc64. Is this ok for trunk? BR, Jeff(Jiufu) Guo gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_const

[PATCH V2] fsra: gimple final sra pass for paramters and returns

: bfxil_1.c and pr101908-3.c). Is this ok for trunk, or continue to enhance the patch? BR, Jeff (Jiufu Guo) PR target/108073 PR target/69143 gcc/ChangeLog: * cfgexpand.cc (expand_value_return): Update for rtx eq checking. (expand_return): Update for sclarized

Ping^5 [PATCH] add rlwinm pattern for DImode for constant building

Hi, Gentle ping... BR, Jeff(Jiufu) Guo Jiufu Guo writes: > Hi, > > Gentle ping. > > BR, > Jeff(Jiufu) Guo > > Jiufu Guo writes: > >> Hi, >> >> Gentle ping ... >> >> Jiufu Guo writes: >> >>> Hi, >>> >>&

Re: [PATCH V4] report message for operator %a on unaddressible operand

Hi, "Kewen.Lin" writes: > Hi Jeff, > > on 2024/6/5 16:30, Jiufu Guo wrote: >> Hi, >> >> For PR96866, when printing asm code for modifier "%a", an addressable >> operand is required. While the constraint "X" allow any kind of

[PATCH V5] report message for operator %a on unaddressible operand

indicate the invalid asm operand. Compare with previous version, test case is updated with -mno-pcrel. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff(Jiufu Guo) PR target/96866 gcc/ChangeLog: * config/rs6000/rs6000.cc (print_operand_address): Emit message for

Re: [PATCH] report message for operator %a on unaddressible exp

Hi, Segher Boessenkool writes: > On Tue, May 14, 2024 at 11:00:38AM +0800, Jiufu Guo wrote: >> >> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc >> >> index 117999613d8..50943d76f79 100644 >> >> --- a/gcc/config/rs6000/rs6000.cc

Re: [PATCH] report message for operator %a on unaddressible exp

Hi, Segher Boessenkool writes: > Oh, btw: > > On Tue, May 14, 2024 at 11:00:38AM +0800, Jiufu Guo wrote: >> >> --- a/gcc/config/rs6000/rs6000.cc >> >> +++ b/gcc/config/rs6000/rs6000.cc >> >> @@ -14659,6 +14659,12 @@ print_operand_address (FILE *f

Re: [PATCH] report message for operator %a on unaddressible exp

Hi, Segher Boessenkool writes: > On Tue, May 14, 2024 at 05:53:56PM +0800, Jiufu Guo wrote: >> Thanks so much for your great review! >> Reference other messages, I'm wondering "invalid %%a value" may be >> acceptable, or "invalid %%a address expressio

[PATCH] report message for operator %a on unaddressible operand

indicate the invalid asm operand. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff(Jiufu Guo) PR target/96866 gcc/ChangeLog: * config/rs6000/rs6000.cc (print_operand_address): gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr96866-1.c: New test.

  1   2   3   4   5   6   >