ifcvt/crossjump patch: Fix PR 42496, 21803

[Bernd Schmidt]

On 07/27/2010 09:44 AM, Eric Botcazou wrote:
>> How is this simpler and better than just having a single line calling
>> reorder_insns?  It seems pointless given that it produces the same
>> result, with a lot more effort.
> 
> It's the canonical way of doing this kind of transformations these days.  The 
> underlying machinery is supposed to do all the heavy lifting, you just have 
> to drive it.

That's a non-argument, and false IMO.  Not every optimization can be
represented cleanly as a set of CFG manipulations, and this one can't.
Are you saying we should restrict ourselves to not doing it?

> In particular, I want to avoid kludges like:
> 
> +/* Set to true if we couldn't run an optimization due to stale liveness
> +   information; we should run df_analyze to enable more opportunities.  */
> +static bool block_was_dirty;
> 
> @@ -2182,6 +2449,9 @@ try_optimize_cfg (int mode)
>  	      && try_crossjump_bb (mode, EXIT_BLOCK_PTR))
>  	    changed = true;
>  
> +	  if (block_was_dirty)
> +	    df_analyze ();
> +
>  #ifdef ENABLE_CHECKING
>  	  if (changed)
>  	    verify_flow_info ();
> 
> that shouldn't be necessary.

Still not an argument.  Why shouldn't it be necessary?  It is logical
that by moving code, we change the liveness of registers.  We have to
verify the liveness of registers before moving code, hence, to iterate,
we have to recompute it.


Bernd