This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cfg_layout_split_edge doesn't handle the general case correctly


Steven Bosscher <stevenb@suse.de> wrote on 21/08/2004 02:33:17:

> On Saturday 21 August 2004 01:18, James E Wilson wrote:
> > On Fri, 2004-08-20 at 07:52, Mostafa Hagog wrote:
> > > This is wrong because if we have a fullthru edge going of a block
next_bb
> > > must
> > > be the destination of that fallthru edge.
> >
> > OK, this is helpful.  But you have left out info again.  Where is the
> > code that assumes that a fallthru edge must be the next block?
>
> Where it does, it should be fixed, because it would be a bug.  The
> cfglayout mode was "invented" to make this requirement go away.  In
> cfglayout mode the fallthru edges may point to any arbitary block,
> *not* to next_bb like in the "normal", linear RTL CFG.

The source of the problem that I am facing is that I wanted to move to
using
the cfglayout mode in SMS (which previously was using cfg RTL mode).
The source of my confusion was that I didn't know the above fact:
in cfglayout mode there is no special meaning for next_bb.
While debugging SMS (after moving to use cfglayout mode)
I found out that commit_edge_insertions - that assumes the special meaning
of bb_next- screwed things up because "cfg_layout_split_edge didn't set
bb_next
correctly". Later I learned (from this discussion) that
commit_edge_insertions
mustn't be used in cfglayout mode.

BTW, I would expect to have an equivalent to commit_edge_insertions
in the cfglayout mode.

And, a comment in cfg_layout_split_edge in the line setting the bb_next
would help others not to be confused in the future.

Mostafa.

>
> Gr.
> Steven
>



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]