Fix PR41454 (dom miscompiles stuff)
Jeff Law
law@redhat.com
Thu Sep 24 15:21:00 GMT 2009
On 09/24/09 07:32, Michael Matz wrote:
> Hi,
>
> the basic issue is that dom doesn't call update_stmt early enough, but
> instead queues this to when leaving the block. That's not going to work
> as leave_block can thread over backedges. There are counter-measures to
> not generate endless loops by that but they depends on updated statement
> for the target block (a dom parent in our case, hence not already
> processed by leave_block, hence with modified but not updated statements).
> In particular FOR_EACH_SSA_USE_OPERAND doesn't work with unupdated
> statements.
>
> The fix is obviously to call update_stmt early enough. With that we can
> also do away with the stmts_to_rescan set, that since some time wasn't
> doing interesting things anymore except defering update_stmt calls. It
> once was used to defer changing virtual ops that are part of the hash
> code, that has to stay the same until avail expressions are removed. But
> that can't happen anymore, and even more so even the removal code doesn't
> really seem to rely on this awkward condition.
>
> Fixes the testcase, regstrapping on x86_64-linux in progress (all
> langs+Ada). Okay if that passes?
>
>
It's been a horribly long time since I looked at any of this code -- I
guess my only question is under what conditions could we previously
expose new variables? Did it only occur for virtuals? Note, I'm not
objecting to the patch, just trying to remember why the code was written
in that way.
As for Richard's comments re: may_have_exposed_new_symbols, I agree, if
we stop queueing statements for rescanning, all the
may_have_exposed_new_symbols goo can go away.
jeff
More information about the Gcc-patches
mailing list