Re: Repost: RFA: re-instate struct_equiv code

[Joern RENNECKE <joern dot rennecke at st dot com>]

Bernd Schmidt wrote:

>  
> I found one [transformation] that doesn't [keep register life 
> information intact].  Replacing condjumps with unconditional jumps 
> with try_redirect_by_replacing_jump can kill flag registers.

We could handle this by keeping a list of such flag registers that are 
now potentially dead.  If the available liveness information indicates 
that a register is live, but a previous transformation
has potentially killed that register, we have to treat the liveness as 
unknown.  As it happens, if we treat a register as live which isn't, 
cross-jumping will not make an invalid transformation -
it might only miss some possible optimizations because it avoids 
clobbering a dead register.
Moreover, if we can guanrantee that all liveness inconsistencies are of 
the form that we think a register is live which isn't, a valid way to 
make the information of two blocks with identical
successors match is to calculate the intersection.  I.e. 
struct_equiv_init can use bitmap_and to calculate common_live.  We must 
not assume that a register is dead which is live; cross-jumping is far 
from unique in this requirement, so any violation of this requirement is 
a bug.
On the other hand, comparing the regsets to decide if the blocks match 
can get us wrong negatives, which we can avoid by considering the blocks 
matching if they only differ in
registers that might have become dead (or stack regs; we exclude them 
already from the match).  Likewise, the sanity checks must not insist on 
liveness matching for registers that
might have become dead.  Both these issues can be addressed by keeping 
track of the potentially dying registers and taking them into account 
inside struct_equiv_regs_eq_p.

If we want to get more fancy, we can add some logic to set a flag when 
we potentially miss optimization opportunities because of uncertainties 
about the liveness of a register,
which is again cleared at the start of every iteration of cleanup_cfg.  
If we have run out of optimization opportunities with our current, 
known-imprecise information,  but have
noted some potential opportunities with updated information, we can 
re-calculate liveness information.