[PATCH V2] rs6000: add clober and guard for vsx_stxvd2x4_le_const[pr116030]

ndirect_operand" is guarded. Bootstrap®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu) Guo PR target/116030 gcc/ChangeLog: * config/rs6000/vsx.md (vsx_stxvd2x4_le_const_): Add clobber and guard with !altivec_indexed_or_indirect_operand. gcc/testsui

[PATCH V2] add rlwinm pattern for DImode for constant building

is able to be built by 'lis/li; rlwinm'. Compare with previous patch, https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649792.html this version adds option '-mpowerpc64' to let the test cases can be run with -m32. Bootstrap and regtest pass on ppc64{,le}. Is ok for trunk? J

Re: [PATCH] rs6000: allow split vsx_stxvd2x4_le_const after RA[pr116030]

Hi, Sam James writes: > Jiufu Guo writes: > >> Hi, >> >> Previous, vsx_stxvd2x4_le_const_ is introduced for 'split1' pass, >> so it is guarded by "can_create_pseudo_p ()". >> While, it would be possible to match the pattern of this i

[PATCH] rs6000: allow split vsx_stxvd2x4_le_const after RA[pr116030]

p®test pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu) Guo PR target/116030 gcc/ChangeLog: * config/rs6000/vsx.md (vsx_stxvd2x4_le_const_): Allow insn after RA. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr116030.c: New test. --- gcc/

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

or trunk? BR, Jeff (Jiufu Guo) PR target/108073 PR target/65421 PR target/69143 gcc/ChangeLog: * calls.cc (precompute_register_parameters): Prepare callee argument from caller parameter. * cfgexpand.cc (expand_value_return): Update 

Re: [PATCH V7 1/3] split complicate 64bit constant to memory

Hi, I would like to have a ping for these patches. BR, Jeff(Jiufu Guo) Jiufu Guo writes: > Hi, > > Sometimes, a complicated constant is built via 3(or more) > instructions. Generally speaking, it would not be as fast > as loading it from the constant pool (as the discussio

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

ert to MEM...) for them. And they also need additional code in expander (like expand_SET_RET). So, SRA would be still a good choise to optimize those 'returns'. Bootstrapped/regtested on ppc64{,le}, x86_64. With known behavior changes in pr88873.c, pr101908-3.c. Is this ok for trunk? BR, Jeff (J

Ping^6 [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. >> >> BR, >> Jeff(Jiufu) Guo >> >> Jiufu Guo writes

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

m32 -mpowerpc64" variation on ppc64. Is this ok for trunk? BR, Jeff(Jiufu) Guo gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_const): Split constant to pool for "-m32 -mpowerpc64". gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr63281.c: Allow checking

[PATCH V7 3/3] slight tune heuristic min_insns_constant_in_pool

an build a constant through two instructions. This patch tune the parameter rs6000_min_insns_constant_in_pool for TARGET_PREFIXED and TARGET_32BIT. Bootstrap and regtest pass on ppc64 and ppc64le. Is this patch ok for trunk? BR, Jeff(Jiufu) Guo gcc/ChangeLog: * config/rs6000

[PATCH V7 1/3] split complicate 64bit constant to memory

ile, IMHO, this patch would be still do the right thing. Compare with the previous version: This patch serie adds one more patch to tune the threshold for power10. Boostrap & regtest pass on ppc64{,le}. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/63281 gcc/ChangeLog:

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

4. With known behavior changes in pr88873.c, pr101908-3.c and bfxil_1.c(aarch64). Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/108073 PR target/65421 PR target/69143 gcc/ChangeLog: * calls.cc (precompute_register_parameters): Prepare callee argument fr

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

"Kewen.Lin" writes: > Hi Jeff, > > on 2024/7/16 13:39, 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 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

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

[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

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

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

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

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

Hi, Gentle ping. BR, Jeff(Jiufu) Guo Jiufu Guo writes: > Hi, > > For PR96866, when printing asm code for modifier "%a", an addressable > operand is required. While the constraint "X" allow any kind of > operand even which is hard to get the address d

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

access parameter which in memory * More cases/targets checking Bootstrapped/regtested on ppc64{,le}, x86_64. Is this ok for trunk? BR, Jeff (Jiufu Guo) PR target/108073 PR target/69143 gcc/ChangeLog: * cfgexpand.cc (expand_value_return): Update for rtx eq checking

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

sed any more. 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): Split constant to memory under -m64. gcc/testsuite/ChangeLog: * gcc.target/p

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

ber of the constant. 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): Split constant to pool for &quo

Re: [PATCH V4 1/2] split complicate 64bit constant to memory

Hi Segher, Thanks a lot for your review! Segher Boessenkool writes: > Hi! > > On Tue, Jun 11, 2024 at 04:37:25PM +0800, Jiufu Guo wrote: >> Sometimes, a complicated constant is built via 3(or more) >> instructions. Generally speaking, it would not be as fast >

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

owing patch is drafted to support this functionality for 32bit(-m32) with -mpowerpc64. 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 split

[PATCH V4 2/2] split complicate 64bit to constant pool under -m32 -mpowerpc64

m32 -mpowerpc64" variation on ppc64. Is this ok for trunk? BR, Jeff(Jiufu) Guo gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_const): Support splitting constant to pool for "-m32 -mpowerpc64". gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr6

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

Hi, Gentle ping ... Jiufu Guo writes: > 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 reg

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

indicate the invalid asm operand. Compare with previous version, changelog and emit message are updated. 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_addres

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

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

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

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

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

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

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

,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. * 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

ong_const' is updated to check 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):

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 the cur

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 (query_positio

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

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

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

,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

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

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_bug.cgi?id

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

[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

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

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

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

[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

[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

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

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

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

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

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

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

[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

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

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

/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

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

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

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

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

  1   2   3   4   5   6   >