This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC patch: invariant addresses too cheap
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: Paolo Bonzini <bonzini at gnu dot org>, Richard Guenther <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org, rdsandiford at googlemail dot com
- Date: Sun, 15 Nov 2009 17:48:13 +0100
- Subject: Re: RFC patch: invariant addresses too cheap
- References: <Pine.LNX.4.64.0910191743440.15566@wotan.suse.de> <f865508f0910200506m1664a75et9dce10aa7fa094de@mail.gmail.com> <878werq41v.fsf@firetop.home> <hch59e$tpv$1@ger.gmane.org> <84fc9c000910310414l40824315m45ff282e98e3b640@mail.gmail.com> <4AEC1C84.9050606@gnu.org> <873a4zpth9.fsf@firetop.home> <4AEC48FF.7000808@gnu.org> <871vkiy24o.fsf@firetop.home> <874ooxmkf8.fsf@firetop.home>
> which is sensible enough. ?But if an invariant is only used in places
> where it is "cheap", why aren't we allowing fwprop2 to propagate them?
> I.e. why don't we let loop-invariant.c act as normal and relax the
> fwprop2 condition:
>
> ?/* Do not propagate loop invariant definitions inside the loop. ?*/
> ?if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
> ? ?return;
>
> in cases where we think propagating an invariant address is "cheap"?
> This feels like a more general fix, since it would also cope with
> hoisting done at the tree level or by GCSE.
This makes sense. However it is tricky because of PR30907 which
we don't want to pessimize. Basically the only way to validate these
patches would be to run nullstone. :-(
Paolo