This is the mail archive of the
mailing list for the GCC project.
Re: needless deep recursion in gt-c-decl.h
- From: Geoff Keating <geoffk at geoffk dot org>
- To: per at bothner dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 5 Aug 2002 10:21:38 -0700
- Subject: Re: needless deep recursion in gt-c-decl.h
- References: <3D3E1AFA.email@example.com> <200207240443.g6O4hx418758@desire.geoffk.org> <3D3E34F6.firstname.lastname@example.org> <200207240529.g6O5Thw18855@desire.geoffk.org> <3D3E47C0.email@example.com> <200207242151.g6OLp7W19902@desire.geoffk.org> <3D401801.firstname.lastname@example.org> <200207251825.g6PIPDf21554@desire.geoffk.org> <3D408B37.email@example.com> <200207302314.g6UNEab06587@desire.geoffk.org> <3D473258.firstname.lastname@example.org> <200208011932.g71JWIN10977@desire.geoffk.org> <3D4EB22E.email@example.com>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Mon, 05 Aug 2002 10:13:18 -0700
> From: Per Bothner <firstname.lastname@example.org>
> Geoff Keating wrote:
> > Nearly all of the remainder is still recursion on PREV_INSN fields.
> > This happens because the DECL_RTL of a LABEL_REF will refer to a
> > CODE_LABEL in the middle of the insn chain, and it happens that this
> > is the first place the insn chain is encountered when marking. The
> > label involved is "plus_expr:" in expand_expr, line 7632.
> > expand_expr starts at line 6183, so there's a long way to go back.
> Is there any reason to mark the DECL_RTL of a LABEL_REF? Is there any
> case (baring a serious internal compiler error) where the DECL_RTL
> could possibly be the only reference to an insn? If not, why waste
> time (and stack space) marking it?
I'm sure there are circumstances, for instance when a CODE_LABEL is
deleted because the code that refers to it is unreachable.
Even if this particular case turns out to be impossible, it would be
very hard to make an argument that there's always another reference to
the DECL_RTL; and even if there actually always was another reference,
you'd have to ask yourself whether the (tiny) speed increase is worth
the extra complexity and the maintenance headache.
The patch I finally committed solves this problem in a more general
- Geoffrey Keating <email@example.com> <firstname.lastname@example.org>