This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix PR41454 (dom miscompiles stuff)


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]