> 
> We have the unfortunate situation that expand may leave us with
> unreachable blocks that are required by proper rtl_eh functioning
> (unreachable landing-pads, that is).  This is bad for any verification
> pass the pass manager may want to call that requires dominators to
> be computed (I'm thinking of verifying loop structures, which I really
> want to do after expand as I am trying to preserve loop structures
> from tree loop optimization until after RTL loop optimization).
> 
> This limitation has been introduced with the introduction of
> rtl_eh - and is, IMHO, bad as it exposed a partly broken IL state
> to the passmanager.
> 
> Thus the following patch makes sure we can leave cfgexpand with
> no unreachable blocks around and simply merges the rtl_eh pass
> and expand.
> 
> Yes, we do have several tests in the testsuite where EH landing
> pads get unreachable during expansion, by a disconnect of what
> GIMPLE thinks can throw and what the expanded code sequence says
> (bogus SSE builtin definitions in the x86_64 backend for example,
> see g++.dg/other/i386-1.C for two cases).

Those cases are in fact mostly broken.  When gimple thinks somehting throws
and it does not, it is a missed optimization.
Especially the SSE intrincisc not having NOTHROW.  We should have at least 
tracking PR for them.
> 
> Bootstrap and regtest on x86_64-unknown-linux-gnu running.
> 
> Comments?

This seems OK to me...
>        NEXT_PASS (pass_init_function);
>        NEXT_PASS (pass_jump);
> -      NEXT_PASS (pass_rtl_eh);
>        NEXT_PASS (pass_initial_value_sets);
>        NEXT_PASS (pass_unshare_all_rtl);

IL is deeply irregular until this step, since RTL sharing is nothing any of
other passes are designed to handle and it does not match what rtl.texi says.
I would suggest merging all those into cfgexpand, not just rtl_eh.

Honza

Reply via email to