On Fri, Aug 7, 2009 at 9:22 PM, Richard Henderson<r...@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~
>
>
