This is the mail archive of the gcc-patches@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: Bug fix for optimize_mode_switching / NORMAL_MODE


On Wed, May 29, 2002 at 01:46:24PM +0100, Joern Rennecke wrote:
> Now that I look at the code once more, I see that we have an analogous
> problem for the entry block, and it isn't properly solved: when there
> are other predecessors to an entry block successor than the entry block
> itself, we can incorrectly assume that the entry block sucessor has
> NORMAL_MODE at the start, even if it hasn't.

Indeed.  Splitting the entry edge here would cure that problem.

> Yes, it would; however, you'd have to allocate that fake block, copy the exit
> block to it, redirect all the predecessors of the exit block to that fake
> block, and make an edge betwen the fake block and the exit block.

True.

Well, hmm.  This is pre-reload, thus return insns can't exist yet.
Therefore there are only two ways to have an edge to the exit block:
the last block fallthru and sibcalls.  But sibcalls are calls, and
so we must return to normal mode before the call, so there is only
one exit predecessor to concern ourselves with -- the fallthru block.

At which point the problem seems much reduced, since we can simply
split that one edge.

> At the end, you'd have to remove the edge between exit block and fake block,
> redirect the fake block predecessors back to the exit block, and deallocate.

Actually, you wouldn't have to do anything of the sort.  One, it would
seem that it's possible that code might have been dropped into the block
to return to normal mode.  Two, if the block is really empty, then a
subsequent call to cleanup_cfg should remove the block.


r~


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