From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21280 invoked by alias); 5 Aug 2002 17:21:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21273 invoked from network); 5 Aug 2002 17:21:40 -0000 Received: from unknown (HELO desire.geoffk.org) (12.235.56.190) by sources.redhat.com with SMTP; 5 Aug 2002 17:21:40 -0000 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g75HLcx28171; Mon, 5 Aug 2002 10:21:38 -0700 Date: Mon, 05 Aug 2002 10:21:00 -0000 From: Geoff Keating Message-Id: <200208051721.g75HLcx28171@desire.geoffk.org> To: per@bothner.com CC: gcc@gcc.gnu.org In-reply-to: <3D4EB22E.5010307@bothner.com> (message from Per Bothner on Mon, 05 Aug 2002 10:13:18 -0700) Subject: Re: needless deep recursion in gt-c-decl.h Reply-to: Geoff Keating References: <3D3E1AFA.2010707@bothner.com> <200207240443.g6O4hx418758@desire.geoffk.org> <3D3E34F6.7060805@bothner.com> <200207240529.g6O5Thw18855@desire.geoffk.org> <3D3E47C0.5020100@bothner.com> <200207242151.g6OLp7W19902@desire.geoffk.org> <3D401801.3050609@bothner.com> <200207251825.g6PIPDf21554@desire.geoffk.org> <3D408B37.6090208@bothner.com> <200207302314.g6UNEab06587@desire.geoffk.org> <3D473258.60804@bothner.com> <200208011932.g71JWIN10977@desire.geoffk.org> <3D4EB22E.5010307@bothner.com> X-SW-Source: 2002-08/txt/msg00251.txt.bz2 > Date: Mon, 05 Aug 2002 10:13:18 -0700 > From: Per Bothner > 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 way. -- - Geoffrey Keating