From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15168 invoked by alias); 6 Oct 2003 17:51:35 -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 15156 invoked from network); 6 Oct 2003 17:51:33 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Oct 2003 17:51:33 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A6ZW5-0003eZ-Nu; Mon, 06 Oct 2003 13:51:29 -0400 Date: Mon, 06 Oct 2003 17:51:00 -0000 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Cc: Richard Henderson Subject: Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. Message-ID: <20031006175129.GA13871@nevyn.them.org> Mail-Followup-To: gcc@gcc.gnu.org, Richard Henderson References: <20030922001710.GA24248@alinoe.com> <20030927124920.GA16447@alinoe.com> <20031006174054.GC17794@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031006174054.GC17794@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00163.txt.bz2 On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote: > On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote: > > But tree-ssa (3.5) even adds a location_t to tree_common! > > Not anymore. > > > A suggestion was to use expr wfl, but that is impractical: > > there are too many places where an expressions type is directly > > compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) - > > all of those places would have to be changed to also check for > > a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then > > unwrap the call expr in order to subsequentially be able to > > process it. > > What leads you to believe that this is true? Why would not the > WFL expr just go through expand_expr, and thence to expand_call? Well, wouldn't e.g. operand_equal_p need to handle EXPR_WITH_FILE_LOCATION? I see lots of other places in the optimizers with the same issue. Right now EXPR_WITH_FILE_LOCATION is only used to wrap inline calls, as far as I can see. Even there I suspect it hurts optimization because of this issue. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer