[RFA:] Fix g77.f-torture/compile/970915-0.f, -Os verify_local_live_at_start MMIX

[Hans-Peter Nilsson]

On Tue, 16 Apr 2002, Richard Henderson wrote:
> On Tue, Apr 16, 2002 at 03:14:20AM -0400, Hans-Peter Nilsson wrote:
> > I use the BB_DIRTY to signal this inconsistency, since that flag
> > is there for purpose.
>
> No, BB_DIRTY is set for _any_ change to the block.  Thus this patch
> disables the verify check entirely.

The information in the bb is inconsistent, meaning local changes
may have global effect, and the verify check needs to see that.
How should that information be evident from the "capping"?
BB_DIRTY seemed to be used to signal such inconsistency.
A new flag?

> And, actually, I think this analysis is wrong, or needs more explanation.

If what I try to address below isn't enough, please hint what
you see was inconsistent or contradictory so I can fix it.

> I'd have expected problems to appear when dead code is eliminated globally
> (but not all of it due to the cap), then later dead code is eliminated
> locally (killing more missed earlier).

Yes, I mean that that can happen too, for a more tangled
test-case.

> However, in the failing test case, there is no later dead code elimination,
> which means that the information produced by the first DCE pass was
> inconsistent.  This is the real bug.

I don't understand what you mean, because I think that should be
apparent in what I wrote and in the patch, but I'll try to
rephrase:

A second DCE pass was not done in the loop, because the call to
cleanup_cfg returns false.  cleanup_cfg was supposed to figure
out if any change that was done would have global effect.  But
that function does not take into account the capping effect:
life info is supposed to be correctly stored in the bb
global_live_at_start and global_live_at_end members, but those
are inconsistent due to the capping.

Perhaps you mean that instead of the code below, cleanup_cfg
should take care of noticing the effects of the capping and
return true?  It'd still need to see a flag or something stored
in the bb to signal that global_live_at_end and
global_live_at_start may be inconsistent.

*************** update_life_info (blocks, extent, prop_f
*** 675,683 ****
  	      changed |= propagate_block (bb, tmp, NULL, NULL,
  				prop_flags & (PROP_SCAN_DEAD_CODE
  					      | PROP_KILL_DEAD_CODE));
  	    }

! 	  if (! changed || ! cleanup_cfg (CLEANUP_EXPENSIVE))
  	    break;
  	}

--- 678,693 ----
  	      changed |= propagate_block (bb, tmp, NULL, NULL,
  				prop_flags & (PROP_SCAN_DEAD_CODE
  					      | PROP_KILL_DEAD_CODE));
+ 	      incomplete_life_info |= (bb->flags & BB_DIRTY) != 0;
  	    }

! 	  /* If proper life info couldn't previously be built, and
! 	     something changed, then it's possible that we can build it
! 	     properly on the next round and then have further progress.
! 	     That will not depend on whether there was cfg cleanup.  */
! 	  if (!changed
! 	      || (!cleanup_cfg (CLEANUP_EXPENSIVE)
! 		  && !incomplete_life_info))
  	    break;
  	}

*************** add_to_mem_set_list (pbi, mem)

brgds, H-P