[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 --- Comment #14 from GCC Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:4759383245ac97a5c83c0272f0a831f2a26ea5c1 commit r14-6674-g4759383245ac97a5c83c0272f0a831f2a26ea5c1 Author: Jiufu Guo Date: Tue Dec 19 13:03:06 2023 +0800 treat argp-based mem as frame related in dse 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=30271#c10 also mentioned this idea. And arpg area may be used to pass argument to callee. So, it would be needed to check if call insns are using that mem. PR rtl-optimization/112525 PR target/30271 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 for call insn. (scan_insn): Add mem checking on call usage. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr112525.c: New test. * gcc.target/powerpc/pr30271.c: New test.
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #13 from Jiu Fu Guo --- (In reply to Andrew Pinski from comment #10) > (In reply to comment #9) > > Andrew, > > > > What is your point here? > > My point here is that currently we do: > gi->frame_related = > (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx); > > But if we change it to be: > gi->frame_related = > (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx) > || (base == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM]); > > It would delete the store (at least in a 4.3 based compiler). > arg_pointer_rtx is the incoming argument space so if it is a fixed register > it will be also frame related and we can safely delete the stores to this > space. https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639550.html is using this idea too. And the 'std' in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271#c2 disappeared.
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 luoxhu at gcc dot gnu.org changed: What|Removed |Added CC||luoxhu at gcc dot gnu.org --- Comment #12 from luoxhu at gcc dot gnu.org --- Fixed at least from GCC 4.9.4? $ /opt/at8.0/bin/gcc -O3 -c -S pr30271.c -mstrict-align $ cat pr30271.s .file "pr30271.c" .abiversion 2 .section".toc","aw" .section".text" .align 2 .p2align 4,,15 .globl f .type f, @function f: extsh 9,3 srawi 3,3,16 add 3,9,3 extsw 3,3 blr .long 0 .byte 0,0,0,0,0,0,0,0 .size f,.-f .ident "GCC: (GNU) 4.9.4 20150824 (Advance-Toolchain-at8.0) [ibm/gcc-4_9-branch, revision: 227153 merged from gcc-4_9-branch, revision 227151]" .section.note.GNU-stack,"",@progbits
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-12-29 23:51 --- (In reply to comment #10) Hmm, this patch bootstraps just fine on the 4.3 branch but causes miscompares on the trunk (the 4.3 branch had checking on also when I bootstrapped it on i386-darwin8.11). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #9 from zadeck at naturalbridge dot com 2008-12-15 15:32 --- Andrew, What is your point here? 1) Is it your claim that anything that is arg_pointer_rtx related would automatically qualify as being safe enough to remove dead stores to? or 2) Is it your claim that if we could generalize the game proposed in comment #7 to cover the arg_pointer_rtx's also? Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-16 02:08 --- (In reply to comment #9) Andrew, What is your point here? My point here is that currently we do: gi-frame_related = (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx); But if we change it to be: gi-frame_related = (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx) || (base == arg_pointer_rtx fixed_regs[ARG_POINTER_REGNUM]); It would delete the store (at least in a 4.3 based compiler). arg_pointer_rtx is the incoming argument space so if it is a fixed register it will be also frame related and we can safely delete the stores to this space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-11 04:42 --- So the problem with the stores here is that the base is arg_pointer_rtx which is still a frame pointer related offset. I think the same can be said is true of stack_pointer_rtx too. We only set frame_related for frame_pointer_rtx and hard_frame_pointer_rtx but arg_pointer_rtx will become a frame pointer later one too. The only issue is that there might not be correct dependencies with respect of arg_pointer_rtx. Kenny, Do you agree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
