This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa]: Inserting on an entry block edge seems to cause asplit
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: 22 Nov 2003 23:25:22 -0500
- Subject: Re: [tree-ssa]: Inserting on an entry block edge seems to cause asplit
- References: <502CE3B2-1D59-11D8-9DC6-000A95DA505C@dberlin.org><1069554057.22241.6.camel@p4> <A6133DD6-1D5C-11D8-9DC6-000A95DA505C@dberlin.org>
On Sat, 2003-11-22 at 21:27, Daniel Berlin wrote:
> >> Any clue why it decides it should up and create a fallthru block
> >> between ENTRY_BLOCK
> >> and 0?
> > Err, am I misreading it? It looks like 0 has 2 predecessors, ENTRY and
> > 14. So if you insert on ENTRY->0, you have to split the edge since you
> > can't append to ENTRY...
> Why can't we append to ENTRY again? ENTRY only goes to 0 (by fallthru),
> and it has code associated with it (or so debug_tree_bb claims).
Multiple entry points would have more successors than just BB 0. I
wouldn't expect ENTRY to ever have code associated with it. It ought to
be a symbolic representation of flow coming into the function. The
function ought not be able to put code into the ENTRY or EXIT block,
just on edges from ENTRY and to EXIT. At least in my view..
> Otherwise, this is gonna get ugly, i'm sure.
> This is what i get for trying to fix bugs :P
Any code thats written ought not be assuming block 0 is the first
executed block... or thats a bug. We're suppose to start with successors