[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
fix_loop_structure
of this case (but only as a last resort I think).

Richard.

>         Marek



More information about the Gcc-patches mailing list