------- Comment #11 from wilson at codesourcery dot com 2010-02-06 06:23 ------- Subject: Re: Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
On Thu, 2010-02-04 at 10:48 +0000, rearnsha at gcc dot gnu dot org wrote: > I've been testing the attached patch on ARM (well, thumb) where there's a > similar issue. > Could someone test this on PPC? I tried it on PPC for the two testcases in PR 30282 and PR 42953 and it works for both of them. However, as Andrew Pinski mentioned, this is wrong for some targets, so we would have to make this a target hook to be usable. Meanwhile, I also looked at the thumb testcase, and it looks like a simple matter of emitting a stack_tie insn in thumb1_expand_epilogue before the SP sets are emitted. The ARM port currently only emits the stack_tie insn in the prologue. So we have two possible solutions here: 1) Add a new target hook to control whether sched makes stack pointer sets depend on all MEMs. 2) Emit stack_tie in epilogue always for Thumb and rs6000 ABI_V4, and modify rs6000 stack_tie to use (mem (scratch)) like ARM. I don't feel strongly either way, but considering that the prologue and epilogue code already contain a lot of target dependent magic, I don't see the need for adding more target hooks when all we need is a few small ARM and rs6000 port changes. The second change also makes the RTL self-descriptive. With the first change, we have to make sure that any optimization pass that might move instructions around knows that stack pointers sets are special, and conflict with all MEMs. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
