Re: Notes toward re-implementing EH in gimple

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Aug 10, 2009 at 3:21 PM, Michael Matz<matz@suse.de> wrote:
> Hi,
>
> On Mon, 10 Aug 2009, Richard Guenther wrote:
>
>> >> No and no.  They will eventually resolve to pseudos generated during
>> >> rtl eh expansion.  But to avoid silliness at the gimple level I don't
>> >> want to allow them to appear at random.
>> >
>> > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be
>> > builtin functions with proper attributes.  They wouldn't be moved
>> > upwards over the EH edge because that would introduce effects after
>> > the throwing stmt, and they wouldn't be moved downwards due to use-def
>> > relationships on exc_ptr.1/filter.1 in the EH_DISPATCH/RESX uses.
>>
>> What would these attributes be?  If you want to have the builtin having
>> side-effects it can't be pure or const.
>
> Ah, you got me, I conciously wrote 'proper' :)  Theoretically these
> functions are pure, with the EH edges clobbering global state.  The latter
> might possibly be modeled with PHI nodes on .MEM.  But that would probably
> prevent the below CSEing again :-/

For pure functions there should indeed be PHI nodes for .MEM because
we have new state on the incoming EH edges.  So it might even work.
It doesn't prevent the function from being sinked somewhere, but
nobody is going to do that for reads anyway (fingers crossing).

Richard.

> Hmm.
>
>
> Ciao,
> Michael.