This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR33713: remove -fforce-addr
- From: Richard Guenther <rguenther at suse dot de>
- To: Michael Meissner <michael dot meissner at amd dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, gcc-patches at gcc dot gnu dot org, stevenb dot gcc at gmail dot com, bonzini at gnu dot org, matz at suse dot de, christophe dot harle at amd dot com
- Date: Fri, 30 Nov 2007 11:06:03 +0100 (CET)
- Subject: Re: PR33713: remove -fforce-addr
- References: <20071129175051.GA12296@redhat.com> <20071130000233.GA19742@mmeissner-gold.amd.com>
On Thu, 29 Nov 2007, Michael Meissner wrote:
> On Thu, Nov 29, 2007 at 12:50:51PM -0500, Aldy Hernandez wrote:
> > Hi folks.
> >
> > I'm picking up this patch that Steven attached to the PR but didn't
> > submit to the list. The patch removes support for -fforce-addr.
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
> >
> > I have added a changelog, incorporated the change suggested by Paolo,
> > fixed a typo, and tested it on x86_64-linux. There are no regressions.
> >
> > Is this OK for mainline?
> >
> > PR33713
> > * doc/invoke.texi: Remove -fforce-addr documentation.
> > * expr.c (emit_move_insn): Remove use of flag_force_addr.
> > (expand_expr_real_1): Same.
> > (do_tablejump): Same.
> > Call memory_address instead of memory_address_noforce.
> > * expr.h (memory_address_noforce): Remove prototype.
> > * explow.c (memory_address): Remove support for flag_force_addr.
> > (validize_mem): Same.
> > (memory_address_noforce): Remove.
> > * common.opt: Add dummy documentation for -fforce-addr.
> > * combine.c (can_combine_p): Remove -fforce-addr comment.
> > * config/cris/cris.h: Update CC1_SPEC comment with regards to
> > -fforce-addr.
> > (OPTIMIZATION_OPTIONS): Remove set of flag_force_addr.
> > * config/m68k/m68k.h (PIC_CASE_VECTOR_ADDRESS): Remove comment
> > relating to memory_address_noforce.
> >
> > * gcc.c-torture/compile/20050802-1.c: Remove.
> > * gcc.c-torture/compile/20011113-1.c: Remove.
>
> I'm coming in late to this. Given there were a few examples that were faster
> with -fforce-addr, do we want to remove it without trying to fix the code? I
> didn't see from the bug report that the slowdowns had been addressed.
As it makes us reject valid code this is an easy decision. Also
somebody performed SPEC meansurement and showed that without -fforce-addr
it is actually faster.
Can you give pointers to the few examples that were faster with
-fforce-addr (and that are not only attributed to our bad register
allocator)?
> I also would prefer a deprecated switch get a warning, rather than silently
> accepting it.
In general I agree here, but I don't have a strong opinion for
optimization switches.
Thanks,
Richard.