From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25487 invoked by alias); 16 Aug 2012 14:21:47 -0000 Received: (qmail 25476 invoked by uid 22791); 16 Aug 2012 14:21:45 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Aug 2012 14:21:32 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 6B91AA329D; Thu, 16 Aug 2012 16:21:31 +0200 (CEST) Date: Thu, 16 Aug 2012 14:21:00 -0000 From: Michael Matz To: Diego Novillo Cc: Richard Guenther , Eric Botcazou , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function In-Reply-To: Message-ID: References: <20120809142644.GA11133@virgil.arch.suse.de> <201208101657.41678.ebotcazou@adacore.com> <20120815152104.GB28400@virgil.arch.suse.de> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg01061.txt.bz2 Hi, On Thu, 16 Aug 2012, Diego Novillo wrote: > I like this approach, particularly since it would be used in contexts > where there is no simpler scheme. I'm not crazy about overloading > unused fields, but it's fine if we wrap it around a special accessor. I > suppose we could also make ENTRY/EXIT be a base class for basic_block > and use a real field (but that can wait). Actually the other way around (ENTRY/EXIT be a subclass), as it would be an additional field to the normal basic blocks. But for central data structures I'm usually of the opinion that jumping through hoops just to not enlarge them is quite acceptable :) > There are other pieces of data that are "global" but context-dependent. > I wonder if it wouldn't make sense to encapsulate them in some class > that is controlled by the pass manager and gets updated as it moves from > function to function (it would contain things like cfun, > current_function_decl, etc). And on that topic: I think it makes sense to eventually get rid of one or the other, current_function_decl is always (well, mostly) cfun->decl, if cfun happens to be set. I know there are some roadblocks in front of that goal, but still. Ciao, Michael.