[PATCH][RFC] Merge 'expand' and 'rtl_eh'

[Jan Hubicka]

> On Mon, 19 Mar 2012, Steven Bosscher wrote:
> 
> > On Mon, Mar 19, 2012 at 4:41 PM, Richard Guenther <rguenther@suse.de> wrote:
> > > Comments?
> > 
> > What does rtl_eh do for no-SJLJ exceptions?
> 
> Quoting from except.c
> 
> 'Then, via finish_eh_generation, we generate the real landing pads
>    to which the runtime will actually transfer control.  These new
>    landing pads perform whatever bookkeeping is needed by the target
>    backend in order to resume execution within the current function.
>    Each of these new landing pads falls through into the post_landing_pad
>    label which had been used within the CFG up to this point.  All
>    exception edges within the CFG are redirected to the new landing pads.
>    If the target uses setjmp to implement exceptions, the various extra
>    calls into the runtime to register and unregister the current stack
>    frame are emitted at this time.'
> 
> > Have you tested with SJLJ exceptions? (Can/should we move that code to GIMPLE?)
> 
> No.  The only thing that changes is the time when we call 
> fixup_tail_calls, otherwise the patch should be a no-op basically
> hiding the inconsistent state during the piecewise RTL expansion
> from the pass manager.

As discussed on IRC, we ought to merge the passes that keeps RTL inconsistent
into single pass. Until RTl reaches its specified form (that is after unsharing)
those are not realy independent passes anyway. They just come from historical
way rest_of_compilation function was shaped.

As a followup I will try to cleanup those early stages of compilation getting
rid of pass_jump/pass_jump2 and friends.

Honza
> 
> Richard.