From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7326 invoked by alias); 14 Jun 2003 20:27:04 -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 7315 invoked from network); 14 Jun 2003 20:27:03 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 14 Jun 2003 20:27:03 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 2DF304F908; Sat, 14 Jun 2003 22:27:03 +0200 (CEST) Date: Sat, 14 Jun 2003 21:01:00 -0000 From: Jan Hubicka To: Pop =?iso-8859-2?Q?S=E9bastian?= Cc: Jan Hubicka , Diego Novillo , "gcc@gcc.gnu.org" Subject: Re: [RFC] CFG hooks for rtl/tree specificities Message-ID: <20030614202703.GB9010@atrey.karlin.mff.cuni.cz> References: <20030401145007.GA25362@gauvain.u-strasbg.fr> <20030401154607.GF904@kam.mff.cuni.cz> <20030401161112.GD24512@gauvain.u-strasbg.fr> <1049214194.1149.26.camel@shadowfax> <20030402122311.GA2708@gauvain.u-strasbg.fr> <20030614120913.GH16703@kam.mff.cuni.cz> <20030614184514.GA29567@gauvain.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030614184514.GA29567@gauvain.u-strasbg.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-06/txt/msg01262.txt.bz2 > > > This seems to be different from tree-ssa one where for instance basic > > block removeal does not appear to take care to kill the surrouding > > control flow constructs, just kill the contained statements. > > > > I am not sure how much of the API we can map - I was looking at the edge > > splitting code and don't quite understand how it preserves the CFG > > consistent with the tree representation. > The BB that splits the edge is artificial, and thus it does not have to > modify the underlying representation. What exactly do you mean by artifical BB? > > > I.E when the new basic block is > > created there is no modification into underlying IL made and I have no > > idea how you do decide wehre to place code that eventually will be > > inserted into the BB. > > I would say that this is the job of the bsi_insert*-ers. > It would be interesting to have this interface also at RTL level: > ie. insertions performed with the help of iterators using > bsi_insert_after, bsi_insert_before, and bsi_insert_on_edge. Hmm, I see, bsi_insert_on_edge called on edge between two abstract blocks will call bsi_insert_after on iterator containing the empty block that will in turn look for the followup block that is again empty block and abort (). It also appears to fail in the case the edge is in between abstract block and normal block that starts at a label and this edge comes from goto statement, while the label can be also reached via fallthru. In that case bsi_insert_after appears to insert code at the beggining of parent stmt of the destination block that may be well before the label and thus it is reached by the other ede than it is supposed to. I am not quite sure how good idea is to have basic blocks that do not exists in the underlying code and vice versa. I believe there are too many side cases one can run into. > > I don't think that the tree level insertion of code is confused by the > presence of a new empty/artificial basic block in the flow. > > > Can you please try to take a quick look on what I > > do have on mainline now and let me know you ideas? > > > If I recall correctly, the edge splitting at RTL level inserts code > in the newly created basic block. In some intermediate version, I have It does not insert really anything, just sets up the basic block in RTL representation (you are required to have BASIC_BLOCK note in it that is there mostly to avoid need for the iterators - so we have something to point to even inside empty basic blocks). > also inserted NOP_EXPRs in the newly created BB, but I ended up by not > inserting anything in the new BB since the role of the artificial BB > is only to modify the properties of the CFG, without modifying the > underlying representation. In the loop detector we need a single > back edge (aka. latch) per loop, and thus we have to slightly modify the > properties of the CFG, but the underlying representation does not have to > change. The loop analysis is probably not best example here as it really modifies the CFG for no obvious reason. But OK, I see that you can add machinery to create basic blocks on the edges lazilly once they are used. > > > Concerning the high level constructs, I am not very convienced that we > > actually need it and I would like to proceed on gradual lowering of > > these constructs on gimple level (so at RTL expansion time we do have > > conditional jumps, jumptables and computed jumps constructs same as RTL > > has with exception of conditional jumps being two way jumps with no > > fallthru). > I agree that having a high level DO_EXPR for normalized loops would not > help, since all the information is already well stored in the loops/loop > structures. > > [...] > > First show-stopper in this plan appears to be representation of scoping > > regions and exception handling. Do you think it would be dificult to > > convert it into RTL-style information? > > > I have no idea. Me neither. I have to understand the treessa closer I guess :) Good luck with your exam! Honza