From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25781 invoked by alias); 14 Jun 2003 18:45:22 -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 25712 invoked from network); 14 Jun 2003 18:45:21 -0000 Received: from unknown (HELO gauvain.u-strasbg.fr) (130.79.74.5) by sources.redhat.com with SMTP; 14 Jun 2003 18:45:21 -0000 Received: from pop by gauvain.u-strasbg.fr with local (Exim 3.36 #1 (Debian)) id 19RG1a-00005J-00; Sat, 14 Jun 2003 20:45:14 +0200 Date: Sat, 14 Jun 2003 19:42:00 -0000 To: Jan Hubicka Cc: Diego Novillo , "gcc@gcc.gnu.org" Subject: Re: [RFC] CFG hooks for rtl/tree specificities Message-ID: <20030614184514.GA29567@gauvain.u-strasbg.fr> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030614120913.GH16703@kam.mff.cuni.cz> User-Agent: Mutt/1.4i From: =?iso-8859-1?Q?Pop_S=E9bastian?= X-SW-Source: 2003-06/txt/msg01251.txt.bz2 On Sat, Jun 14, 2003 at 02:09:13PM +0200, Jan Hubicka wrote: > > Hi, > I've already hookized most of the basic RTL CFG API in the mainline. Cool, thanks for working on that. > THis if fragile, but there seems to be no better way. It is very time > consuming to revisit existing code for profile updating. Can you, > please write the code to update profile when new code is added to > tree-ssa even when we don't do profiling on tree-ssa level at the very > moment? > Sure, I'll try to write this code. I have some exams this month, but after that, I will give it a look. > 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. > 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. 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 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. > 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.