From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11934 invoked by alias); 19 Nov 2003 19:06:51 -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 11925 invoked from network); 19 Nov 2003 19:06:50 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 19 Nov 2003 19:06:50 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id D11EE4C0004; Wed, 19 Nov 2003 20:06:49 +0100 (CET) Date: Wed, 19 Nov 2003 19:14:00 -0000 From: Jan Hubicka To: law@redhat.com Cc: Jan Hubicka , Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Tree-SSA self checking infrastructure Message-ID: <20031119190649.GQ16923@atrey.karlin.mff.cuni.cz> References: <20031119182545.GN16923@atrey.karlin.mff.cuni.cz> <200311191900.hAJJ06nI010619@speedy.slc.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311191900.hAJJ06nI010619@speedy.slc.redhat.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-11/txt/msg01016.txt.bz2 Hi, I will give deeper tought to the pointer types. About the other topics... > >> > c) I commonly got hit by the feature of gimple allowing almost > >> > arbitrarily complex constant operands. What about restricting it > >> > into primitive constants + > >> > (plus_expr (nop_expr (addr_exr )) (integer_cst) as the most complex > >> > form? > >> This has been a subject of great debate. I don't think we have a solid > >> answer on where a NOP_EXPR might appear. > > > >It seems to always appear inside the PLUS expr. It seems like natural > >choice. > >Without that we should have to make recursive walk each time we are > >looking for ADDR_EXPR. > The problem is once you allow it in a PLUS (or anywhere else other than the > RHS of a MODIFY_EXPR) that you've changed the gimple grammar and you have > to account for that change in the gimple grammar. ie, you can no longer > make assumptions that the first argument of a PLUS is a gimple variable. > It might now be a NOP. > > That's the fundamental issue -- it changes the grammar. I don't mean allowing some extra. I am seeing these NOP_EXPRs inside ADDR_EXPRs all the time so I assumed they are valid. OK, now I see it is bug, so I will try to fix it (unless Richard already did so). > >> Having a verification step that you don't rename an already renamed > >> variable after a certain point (after the dominator based jump threading) > >> would be good. > >Many passes seems to rewrite variables efter dominater pass. What to > >do? > They rewrite newly exposed variables. ie, they're rewriting VAR_DECLs, > PARM_DECLs, that were addressable, but due to optimizations they are no > longer addressable and thus can be put into SSA form and optimized. This brings me into questions about my tail call updating code. Perhaps I need to re-do SSA form on call cobbered variables after removing the call? > > The exception is the dominator based jump threader where we do rerewrite > existing SSA_NAMEs. In that case we know there are no overlaps as we have > done no optimizations which could have created an overlap. I see. It would be nice to drop a comment somewhere in tree-optimize.c clarifying what can be renamed when. Honza > > Jeff >