Your change to alloc-pool.c

[Jan Hubicka]

> 
> On Wed, 28 Jan 2004, Jan Hubicka wrote:
> > The problem is that after unification with other edge going from same
> > basic block, the code emitting the instruction (if fixed to find proper
> > edge and not use released datastructure) emits it on both code paths,
> > not just on the one originally going via old edge.
> 
> One solution might be to post-pone unifying edges between the same
> pair of basic blocks in one or both of them contain instructions until
> we finally run commit_edge_insertions.

I would preffer avoiding breaking the CFG invariants even when it is
done temporarily.
Even if you do not unify the edges, you lose information what code patch
went by what edge as the instructions may have many control flow effects
at once (imagine tablejump where you got several entries to be same, but
previously they weren't).

Note that this is also bad code generation bug for 3.4, so we should
come with safe fix first too.  The code simply emits instruction on the
edge already removed from CFG so it is really not going to work.
> 
> 
> > Of course the bypassing is possible, but we would have to proactivly
> > create the basic block with instructions we are about to put into split
> > edge, but that would need more massaging of gcse.c to be able to accept
> > new basic blocks appearing and disappearing.
> 
> There's already code to handle this in the jump bypassing pass, as
> redirect_edge_and_branch_force may introduce new basic blocks; the
> variable "bypass_last_basic_block" keeps track of the last basic
> block index when we started and therefore the set of original basic
> blocks for which our data flow is valid.
> 
> 
> I'd be interested to know if you think it would be easy or easier to
> split edges as we go, creating new basic blocks and inserting insns
> there, rather than inserting instructions on edges whilst we're changing
> the CFG?

Changling the CFG as we go is resonably easy and will enable more
bypassing just because we already do have checks that diasable bypassing
when instructions are on edges..
We need to split out the emitting on edge logic from
commit_one_edge_insertion so it accepts instruction to emit and edge to
manipulate with and returns possibly newly create basic block.  This
sounds quite easy to do.

Honza
> 
> WindRiver's compilers, for example, do more aggressive jump bypassing
> than GCC currently does.  However, we can achieve the same effects by
> either running several iterations of jump bypassing and/or incrementally
> updating GCSE's data flow analysis as we redirect edges.
> 
> Roger
> --
>