This is the mail archive of the
mailing list for the GCC project.
Re: Your change to alloc-pool.c
- From: Roger Sayle <roger at eyesopen dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Arnaud Charlet <charlet at ACT-Europe dot FR>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Jan 2004 05:07:24 -0700 (MST)
- Subject: Re: Your change to alloc-pool.c
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.
> 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
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.