Hi Uros,
Would you consider the following variant that disables this optimization when a
red zone is used by the current function? You're right that cfun's
red_zone_size is
recalculated dynamically, but ix86_red_zone_used should be a better "gate" given
that this logic resides very late during compilation, in the output templates,
where
whether or not a red zone is used is known.
On CSiBE, disabling this optimization in non-leaf functions that use a red zone
costs
219 bytes, but remains a significant win over -Os. (Alas the absolute numbers
aren't
comparable as this testing included the 0/-1 write to memory changes).
Tested (overnight) on x86_64-pc-linux-gnu with make bootstrap and make -k check
with no new failures.
2021-12-22 Roger Sayle <[email protected]>
gcc/ChangeLog
PR target/103773
* config/i386/i386.md (*movdi_internal): Only use short
push/pop sequence for register (non-memory) destinations
when the current function doesn't make use of a red zone.
(*movsi_internal): Likewise.
gcc/testsuite/ChangeLog
PR target/103773
* gcc.target/i386/pr103773.c: New test case.
Please let me know what you think. I'll revert, if this tweak doesn't address
your concerns.
Roger
--
> -----Original Message-----
> From: Uros Bizjak <[email protected]>
> Sent: 22 December 2021 08:20
> To: Roger Sayle <[email protected]>
> Cc: GCC Patches <[email protected]>
> Subject: Re: [PATCH] PR target/103773: Fix wrong-code with -Oz from pop to
> memory.
>
> On Wed, Dec 22, 2021 at 9:10 AM Uros Bizjak <[email protected]> wrote:
> >
> > On Tue, Dec 21, 2021 at 1:27 PM Roger Sayle
> <[email protected]> wrote:
> > >
> > >
> > > My apologies for the inconvenience. The new support for -Oz using
> > > push/pop for small integer constants on x86_64 is only a win/correct
> > > for loading registers. Fixed by adding !MEM_P tests in the
> > > appropriate locations.
> > >
> > > This patch has been tested on x86_64-pc-linux-gnu with make
> > > bootstrap and make -k check with no new failures. Ok for mainline?
> > >
> > >
> > > 2021-12-21 Roger Sayle <[email protected]>
> > >
> > > gcc/ChangeLog
> > > PR target/103773
> > > * config/i386/i386.md (*movdi_internal): Only use short
> > > push/pop sequence for register (non-memory) destinations.
> > > (*movsi_internal): Likewise.
> > >
> > > gcc/testsuite/ChangeLog
> > > PR target/103773
> > > * gcc.target/i386/pr103773.c: New test case.
> >
> > Ouch, as pointed out in the PR, this approach clobbers the red zone.
> >
> > Please revert the original patch.
>
> *Maybe* we can use frame->red_zone_size here, but the frame is recalculated
> several times during the compilation. I think it is just too dangerous to use
> push/pop w.r.t. red zone clobbering.
>
> Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index d25453f..489cede 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2217,7 +2217,9 @@
if (optimize_size > 1
&& TARGET_64BIT
&& CONST_INT_P (operands[1])
- && IN_RANGE (INTVAL (operands[1]), -128, 127))
+ && IN_RANGE (INTVAL (operands[1]), -128, 127)
+ && !MEM_P (operands[0])
+ && !ix86_red_zone_used)
return "push{q}\t%1\n\tpop{q}\t%0";
return "mov{l}\t{%k1, %k0|%k0, %k1}";
}
@@ -2440,7 +2442,9 @@
return "lea{l}\t{%E1, %0|%0, %E1}";
else if (optimize_size > 1
&& CONST_INT_P (operands[1])
- && IN_RANGE (INTVAL (operands[1]), -128, 127))
+ && IN_RANGE (INTVAL (operands[1]), -128, 127)
+ && !MEM_P (operands[0])
+ && !ix86_red_zone_used)
{
if (TARGET_64BIT)
return "push{q}\t%1\n\tpop{q}\t%q0";
