Take 3: RFA: re-instate struct_equiv code

[Daniel Berlin]

On Wed, 2006-02-08 at 15:12 +0000, Joern RENNECKE wrote:
> In http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00673.html, Bernd 
> Schmidt wrote:
>  > > Joern RENNECKE wrote:
>  > >
>  > >     * basic-block.h (maybe_killed_reg): Define.
>  > >     (struct control_flow_graph): Add new member x_maybe_killed_regs.
>  > >     (used_by_bb_end): Declare.
>  > >     * flow.c (allocate_bb_life_data): Allocate maybe_killed_regs.
>  > >     (used_by_bb_end): New function.
>  > >     * cfgrtl.c (try_redirect_by_replacing_jump): Update 
> maybe_killed_regs.
>  >
>  >
>  > I'm sorry, but no. This is too ad-hoc, and too brittle. We need to 
> find something more solid. I've had some success moving cross jumping 
> out of the main loop in try_optimize_cfg, I just need to do some timings 
> after adding a life update and reenabling struct-equiv.
> 
> Moving cross-jumping out of the main loop in try_optimize_cfg is a knee-jerk
> reaction, and likely to loose us optimizations.
I very highly doubt this.
While cleanup_cfg is called roughly everywhere, i have a *very very*
hard time believing that every single optimization pass will expose new
cross-jumping opportunities in a way that if you just run this stuff,
say, twice (once early, once late), you won't catch 90-99% of them.

I also have a very hard time believing the ones you don't catch this way
matter so much that it's worth the compilation time hit we currently
take.

--Dan