[PATCH] Another fix for PR54838

Richard Biener richard.guenther@gmail.com
Mon Dec 17 10:26:00 GMT 2012

On Mon, Dec 17, 2012 at 11:16 AM, Marek Polacek <polacek@redhat.com> wrote:
> On Mon, Dec 17, 2012 at 10:27:54AM +0100, Richard Biener wrote:
>> This looks like the wrong place to fix (the delete-basic-block cfghook
>> tryings to fixup loops are incredibly fragile, because usually
>> delete_basic_block
>> is called because of another cfg manipulation takes place).  That is,
>> the right cfghook place would be where the latch edge is deleted (of course
>> you cannot know whether it'll be just redirected - thus the fragility of cfghook
>> fixes for loops).
>> Which pass does this deletion?  The correct fix is to fix that pass to
>> correctly care about the high-level CFG transform it performs.
> It's cse1.  I didn't see any place in there where I could fix things up,
> since it looks we aren't directly manipulating the CFG there (it
> rather find paths, stores them in ebb data, then walks the insns in BBs,
> and calls cse_insn on each of them, but it's so big
> and complex that I'm very likely wrong here), only
> via cleanup_cfg at the end of the pass, which is what calls
> delete_unreachable_blocks->delete_basic_block, here we delete two
> latch nodes.  It seems legal to delete them, because at the end of BBs
> before these latches is an unconditional jump at (label_ref 67).
> I don't know how could we teach the CSE beast to care about high-level
> CFG transformations.  Thanks,

Hmm, I think I remember this case ... (and I fixed it up in
cfg_cleanup I think).

So I suppose cse turns a conditional jump into an unconditional one (but
maybe only cfg_cleanup realizes that)?

I think that whoever figures out the latch edge is never taken ought to fixup
loop structure.  Btw, what also could be done is trying to teach
of this case (but only as a last resort I think).


>         Marek

More information about the Gcc-patches mailing list