Re: PR33713: remove -fforce-addr

[Richard Guenther <rguenther@suse.de>]

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.