Re: [PATCH] Merge from LTO: eh_personality changes

[Richard Guenther <rguenther@suse.de>]

On Tue, 8 Sep 2009, Richard Henderson wrote:

> 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

Yeah, something for further enhancement.

> 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.

Or none at all.  The unwinder seems to check for NULL personality
before calling it.

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

That occured to me as well ... I'll see what I can do tomorrow.

> > > 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.

Ok, I'll leave this one alone for now, too.

Richard.