Take 3: RFA: re-instate struct_equiv code

[Joern RENNECKE]

Bernd Schmidt wrote:

>  
> Downsides to this:
>  - it's harder to understand exactly which inconsistencies are ok
>    rather than disallowing them

You can't disallow them without doing complete data flow recomputations 
(not just updates) all the time.

>
>  - allowing "harmless" inconsistencies increases the risk that
>    something that isn't quite so safe slips through

The way you re-arranged the code, we could still see spurious mismatches.

>  - additional dependencies between cfgrtl.c and crossjumping with the
>    new "maybe_killed_regs" thing.

We only have these when we try to preserve the sanity checks.  Without 
the maybe_killed_regs things, as you put it, the sanity checks are 
either worthless or
themselves dangerous (i.e. aborting for harmless and expected 
inconsistencies).

Thus, if we don't want to keep track of where our information is fuzzy, 
we should just own up to this fact and drop the checks.

>
>
> I think this is way into "too clever" territory and would be a 
> maintenance nightmare.  Without a very good reason I don't think we 
> should go this way if a sane approach works.

No, it's just understanding better what we can actually expect from 
register liveness information.