Re: [PATCH] missing reuire target has_arch_ppc64 for pr106550.c

/ >>> /* { dg-require-effective-target power10_ok } */ >> >> Nit: power10_ok can be dropped. > Yeap, thanks for catch this! > >> >>> +/* { dg-require-effective-target has_arch_ppc64 } */ >> OK with the nits above tweaked, thanks. Thanks, pushed as r15-790. BR, Jeff(Jiufu) Guo > > Thanks again. > > BR, > Jeff(Jiufu) Guo > >> >> BR, >> Kewen

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

Hi, Hans-Peter Nilsson writes: > On Mon, 20 May 2024, 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 >> ope

Re: [PATCH] missing reuire target has_arch_ppc64 for pr106550.c

Hi, "Kewen.Lin" writes: > Hi Jeff, > > subject typo: s/reuire/require/ Thanks! > > on 2024/5/23 09:11, Jiufu Guo wrote: >> Hi, >> >> Case pr106550.c is testing constant building for 64bit >> register. So, this case requires target of has_arch_p

[PATCH] missing reuire target has_arch_ppc64 for pr106550.c

Hi, Case pr106550.c is testing constant building for 64bit register. So, this case requires target of has_arch_ppc64. Bootstrap and regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff(Jiufu) Guo --- gcc/testsuite/gcc.target/powerpc/pr106550.c | 1 + 1 file changed, 1 insertion(+) diff

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

indicate the invalid asm operand. Compare with previous version, code comments and message are updated. Bootstrap 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

Re: [PATCH] add rlwinm pattern for DImode for constant building

Hi, Gentle ping ... BR, Jeff(Jiufu) Guo Jiufu Guo writes: > Hi, > > 'rlwinm' pattern is already well used for SImode. As this instruction > can touch the whole 64bit register, so some constants in 64bit(DImode) > can be built via 'lis/li+rlwinm'. To achieve this

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

Hi, Jiufu Guo writes: > 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 >

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

Hi, Sorry for missing word "V2". According to previous comments, this version updates: 1. using different 'tests' for the invalid case, and put the msg to a better and safer possition. 2. refine the words of the message. 3. updates the test case a little for comments. BR, Jeff(Jiufu)

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

indicate the invalid asm operand. Bootstrap 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.

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 expression in

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 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, "Kewen.Lin" writes: > Hi, > > on 2024/5/14 11:00, Jiufu Guo wrote: >> Hi, >> >> Thanks a lot for your helpful review! >> >> "Kewen.Lin" writes: >> >>> Hi, >>> >>> on 2024/5/13 10:57, Jiuf

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

Hi, Thanks a lot for your helpful review! "Kewen.Lin" writes: > Hi, > > on 2024/5/13 10:57, Jiufu Guo wrote: >> Hi, >> >> For PR96866, when gcc print asm code for modifier "%a" which requires >> an address operand, while the operand is wi

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

Hi, Thanks for your helpful comments! Segher Boessenkool writes: > Hi! > > On Mon, May 13, 2024 at 10:57:12AM +0800, Jiufu Guo wrote: >> For PR96866, when gcc print asm code for modifier "%a" which requires >> an address operand, > > It requires a *memory

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

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. * gcc.target/powerpc/pr96866-2.c: New test. --- gcc/con

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

Hi, Ping this patch, look forward to comments. Jeff (Jiufu Guo) Jiufu Guo writes: > Hi, > > As known there are a few PRs (meta-bug PR101926) about > accessing aggregate param/returns which are passed through registers. > > We could use the current SRA pass in a special

[PATCH] add rlwinm pattern for DImode for constant building

if a constant is able to be built by 'lis/li; rlwinm'. Bootstrap and regtest pass on ppc64{,le}. Is this patch ok for trunk (when stage1 is open)? Jeff (Jiufu Guo). gcc/ChangeLog: * config/rs6000/rs6000-protos.h (can_be_rotated_to_lowbits): Add new parameter. * config/rs6000

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

Hi, Ping this RFC, look forward to comments for the incoming stage1... Jeff (Jiufu Guo) Jiufu Guo writes: > Hi, > > As known there are a few PRs (meta-bug PR101926) about > accessing aggregate param/returns which are passed through registers. > > We could use th

Re: [PATCH] s390: avoid peeking eof after __vector

Hi, I would like to ping this patch. Jeff (Jiufu Guo) Jiufu Guo writes: > 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 (Jiu

[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 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 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

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

ee 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 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

[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

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 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'. >> >> While

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 >>>>&

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

/pipermail/gcc-patches/2023-December/639492.html This verion is refreshed and updated testcase name. Bootstrap 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 pli for 34bit cons

[PATCH V4 1/3]rs6000: accurate num_insns_constant_gpr

mit 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/rs600

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

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_bu

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 to build this

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

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

. Bootstrap 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

[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 V3 2/3] Using pli for constant splitting

/pipermail/gcc-patches/2023-November/636567.html This verion is refreshed and added with a new testcase. Bootstrap 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 pli for 34bit cons

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

m 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 constan

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

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 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. >> For example:

Ping: [PATCH V2] introduce light expander sra

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 various targe

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

tches/2023-October/634196.html This verion updates a testcase to cover this functionality. Bootstrap 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 pli for 34bit constant. gcc

[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 1/3]rs6000: update num_insns_constant for 2 insns

tions). 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 for tru

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] 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 V2] introduce light expander sra

n and accessed via memory. "foo(struct S arg) {bar ();}" 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): New class. (struct expand_sra): New class.

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, >>>> >&

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 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. >> >> Bootstrap pass

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_c

[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

[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 pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_long_const

[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: *

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

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

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] 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 >

[PATCH] early outs for functions in rs6000.cc

are 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

[PATCH V1] use more get_range_query

tches/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

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] 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):

[PATCH V1] introduce light expander sra

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 access): New class. (struct expand_sr

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 cou

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 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_fro

[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?

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: >

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 loo

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

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 >> v

[PATCH] light expander sra

ting 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) PR target/65421 gcc/ChangeLog:

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

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.

[PATCH] check undefine_p for one more vr

d_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/ChangeLog:

[PATCH 2/2] testcase: rename pr111303.c to pr111324.c

Hi, When commit the fix for pr111324, the test cases was named as pr111303.c by mistake. Here, rename it to pr111324.c Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr111303.c: Rename to ... * gcc.dg/tree-ssa/pr111324.c

[PATCH 1/2] using overflow_free_p to simplify pattern

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. Bootstrap & regtest pass on ppc64{,le} and x86_64. Is this ok for trunk? BR, Jeff (Jiufu) gcc/ChangeLog: * match.pd ((t * 2) / 2): Update to

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

Hi, I would like to have a ping. BR, Jeff (Jiufu Guo) Jiufu Guo writes: > 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: > *(long long*)buff = di; > float f = *(float*)

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

Hi, I would like to have a ping. BR, Jeff (Jiufu Guo) Jiufu Guo writes: > Hi, > > Currently, we have the pattern "movsf_from_si2" which was trying > to support moving high part DI to SF. > > The pattern looks like: XX:SF=bitcast:SF(subreg(YY:DI>>32),

Ping [PATCH] rs6000: mark tieable between INT and FLOAT

Hi, I would like to have a ping. BR, Jeff (Jiufu Guo) Jiufu Guo writes: > Hi, > > For PowerPC, some INT mode and FLOAT modes can be marked as tieable, > for example: DI<->DF. > One note SFmode is special, it would only tieable with itself. > > I updated pre

Re: [PATCH] Checking undefined_p before using the vr

Hi, Andrew MacLeod writes: > On 9/12/23 21:42, Jiufu Guo wrote: >> Hi, >> >> Richard Biener writes: >> >>> On Thu, 7 Sep 2023, Jiufu Guo wrote: >>> >>>> Hi, >>>> >>>> As discussed in PR111303: >>>&

[PATCH] use local range for one more pattern in match.pd

RNS_NONNULL inline range_query * get_range_query (const struct function *fun) { return (fun && fun->x_range_query) ? fun->x_range_query : _ranges; } So, using "get_range_query" would cover more case. For example, the test case of "pr111303.c". Bootstrap pass on pp

Re: [PATCH] Checking undefined_p before using the vr

Hi, Richard Biener writes: > On Thu, 7 Sep 2023, Jiufu Guo wrote: > >> Hi, >> >> As discussed in PR111303: >> >> For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)", >> Even if "X" has value-r

Re: [PATCH V5 1/4] rs6000: build constant via li;rotldi

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 > value which "li" can generated, then "li;rotldi" can be used to build > the constant. > > Compare with th

[PATCH] Checking undefined_p before using the vr

s always false). And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in "bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5". So, before using "vr3", it would be safe to check "!vr3.undefined_

Re: [PATCH V6] Optimize '(X - N * M) / N' to 'X / N - M' if valid

Hi, Richard Biener writes: > On Fri, 1 Sep 2023, Jiufu Guo wrote: > >> Hi, >> >> Integer expression "(X - N * M) / N" can be optimized to "X / N - M" with >> the below conditions: >> 1. There is no wrap/overflow/underflow. >>

[PATCH V6] Optimize '(X - N * M) / N' to 'X / N - M' if valid

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624801.html This patch adds comments and update the pattern on "(t + C)" to be more tight. Bootstrap & regtest pass on ppc64{,le} and x86_64. Is this patch ok for trunk? BR, Jeff (Jiufu Guo) PR tree-optimization/108757 gcc

[PATCH V4 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-July/623533.html "highpart DI-->SF" is put to a seperate patch. Pass bootstrap and regression on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * confi

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

offset of "subreg" is hard code 0, which only works for LE. "movsf_from_si2" is updated to cover BE for "subreg", and cover the logical shift for ":DI>>32". Pass bootstrap and regression on ppc64{,le}. Is this ok for trunk? BR,

Re: [PATCH V1 1/2] light expander sra v0

Hi Richard, Thanks so much for your great review! Richard Biener writes: > On Wed, 23 Aug 2023, Jiufu Guo wrote: > >> >> Hi, >> >> I just updated the patch. We could review this one. >> >> Compare with previous patch: >> https://gcc.gnu.o

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

Hi Richard, Thanks a lot for your great comments! Richard Biener writes: > On Tue, 29 Aug 2023, Jiufu Guo wrote: > >> >> Hi Richard, >> >> Thanks a lot for your quick reply! >> >> Richard Biener writes: >> >> > On Tu

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

Hi Richard, Thanks a lot for your quick reply! Richard Biener writes: > On Tue, 29 Aug 2023, Jiufu Guo wrote: > >> >> Hi All! >> >> "rguenth at gcc dot gnu.org" writes: >> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66 &g

Re: Ping^^ [PATCH V5 2/2] Optimize '(X - N * M) / N' to 'X / N - M' if valid

Hi Richard, Thanks a lot for your review! Richard Biener writes: > On Wed, 23 Aug 2023, guojiufu wrote: > >> Hi, >> >> I would like to have a gentle ping... >> >> BR, >> Jeff (Jiufu Guo) >> >> On 2023-08-07 10:45, guojiufu

Bind RTL to a TREE expr (Re: [Bug target/111166])

; insns fully define the reg. > > Jiufu Guo is working to improve what we choose for DECL_RTL, but for > incoming params / outgoing return. This is a case where we could, > with -fno-tree-vectorize, improve DECL_RTL for an automatic var and > choose not TImode but something like a (concat:

[PATCH] rs6000: mark tieable between INT and FLOAT

Hi, For PowerPC, some INT mode and FLOAT modes can be marked as tieable, for example: DI<->DF. One note SFmode is special, it would only tieable with itself. I updated previous patch more reasonable: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html Bootstrap and regtest pass

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

Hi, If a constant is possible to be rotated to/from a positive or negative value which "li" can generated, then "li;rotldi" can be used to build the constant. Compare with the previous version: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623528.html This patch just did minor changes to

[PATCH V1 1/2] light expander sra v0

g-require-effective-target powerpc_elfv2 } */ +/* { dg-require-effective-target has_arch_ppc64 } */ + +typedef struct FLOATS +{ + double a[3]; +} FLOATS; + +/* 3 lfd after returns also optimized */ +/* FLOATS ret_arg_pt (FLOATS *a){return *a;} */ + +/* 3 stfd */ +void st_arg (FLOATS a, FLOATS *p)

Re: [PATCH 1/2] light expander sra v0

Hi, Jiufu Guo writes: > Hi, > > There are a few PRs about the issues on the struct parameters and > returns, like PRs 69143/65421/108073. > > we could consider introducing a light SRA in the expander to > handle those parameters and returns in aggregate type, if they

[PATCH 2/2] combine nonconstant_array walker and expander_sra walker

-redhat-linux, and powerpc64{,le}-linux-gnu. Is it ok for trunk? BR, Jeff (Jiufu Guo) gcc/ChangeLog: * cfgexpand.cc (discover_nonconstant_array_refs): Deleted. (struct array_and_sra_walk): New class. (pass_expand::execute): Call scan_function on array_and_sra_walk

  1   2   3   4   5   6   >