Re: Notes toward re-implementing EH in gimple

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Aug 7, 2009 at 9:22 PM, Richard Henderson<rth@redhat.com> wrote:
> On 08/06/2009 12:35 PM, Richard Henderson wrote:
>>
>> ?{ exc_ptr, filter } = EH_LANDING_PAD;
>>
>> ? ? ? ?Placeholder for the landing-pad rtl. ?Has 2 outputs
>> ? ? ? ?for both the exception pointer and the filter.
>
> I'm going to drop this construct. ?Instead, I'm going to mark
> the label, and have the landing pad code be emitted as it
> currently is by the rtl. ?This will prevent any problems with
> the landing pad code being moved away from the start of the
> block.
>
> I'm going to adjust the rtl code so that it generates different
> pseudos for exc_ptr and filter for each region. ?These will be
> accessible from gimple with the EXC_PTR_EXPR and FILTER_EXPR
> tree codes.
>
> EXC_PTR_EXPR and FILTER_EXPR will be expanded to take the EH
> region number as a parameter. ?Since they no longer need to be
> saved and restored, they will no longer be gimple lvalues.
>
> In gimple, the landing pad will be generated as
>
> L.N:
> ?exc_ptr.1 = EXC_PTR_EXPR (N);
> ?filter.1 = FILTER_EXPR (N);

Will exc_ptr.1 and filter.1 be gimple registers?  Does the above have
virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR
or FILTER_EXPR load?

Can we CSE FILTER_EXPR (N) and EXC_PTR_EXPR (N)?

> ie, copied into normal variables for use. ?These can be moved
> about, or deleted, as the optimizer desires.
>
> All of this seems much cleaner than what I initially imagined.

Thanks for cleaning this up.

Richard.

>
> r~
>
>