Re: [PATCH] Merge from LTO: eh_personality changes

[Richard Henderson <rth@redhat.com>]

On 09/08/2009 05:37 AM, Richard Guenther wrote:
> Hmm, ok.  So how about setting DECL_EH_PERSONALITY during eh-lowering
> and only for functions with a non-empty EH tree.  We then would
> disallow inlining functions with different non-NULL personality.

I suppose we could do better than that -- only record the
personality if there are runtime types involved.  So that
if there are only cleanups we don't prevent merging.  And
if we get to the end and find personality is still unset,
then we can use the default C personality from libgcc.

I might think we'd record this in cfun->eh, not on the
decl though...

>> The only thing I can think of is to record the fact that the
>> GIMPLE_TRY came from c++/java in the eh_region tree, which would
>> allow the RESX expander to emit the proper function for this
>> particular region.  It's not elegant, but it should work.
>
> With your EH rewrite we could make this function explicit in the IL,
> can we?

We can.  Though I was considering recording a flag rather than
the exact decl.  I do not want to encourage ABIs to muck about
with the generic EH representation.


r~