Re: [tree-ssa] dom1 bug.

[law at redhat dot com]

In message <1071671615.13039.311.camel@p4>, Andrew MacLeod writes:
 >
 >
 >Here's the first bit of fallout from using my operand freelist.
 >
 >dom1 appears to lose VDEFs from time to time when it rewrites stmts. A
 >lot of the failures I am seeing are related to dropped VDEFS.
 >
 >This illustrates the point: Compile with -O2 and look at the dom1
 >listing
 >
 >Andrew
 >
 >
 >/* This is testcase 990130-1.c.  Compile with -O2 */
The problem, at least at a high level is that we mark the asm to be
rescanned since we propagated values into it (which can expose new
variables).

We rescan and rebuild the virtual operands for the asm.  We find that
we no longer can modify "count", the count 10 = VDEF <count_4> gets
dropped.

Which in turn leaves the dangling VUSE for count_10.

Marking the statement with the dangling VUSE for rescanning does not
help.

I see two approaches to address this class of problems, neither is
particularly appealing.

Anytime we make a change to a statement which can cause virtual defs
to disappear, then we need to either mark any virtual defs which
disappear as needing to be re-renamed or we need to force a copy 
propagation of the RHS of the virtual def which is going to disappear.


Interestingly enough mark_new_vars_to_rename has a comment which implies it
does the former, but only in certain circumstances.    I'll have to look
at that code more closely.

[ Luckily all the passes which expose new variables run through 
  mark_new_vars_to_rename, so in theory if we fix mark_new_vars_to_rename
  then we don't have to worry about fixing ccp, dom, sra, etc individually. ]

jeff