This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Merge from LTO: eh_personality changes


On Sat, 5 Sep 2009, Richard Henderson wrote:

> On 09/05/2009 10:24 AM, Richard Guenther wrote:
> > > Also, I think you need to add something to prevent inlining of functions
> > > that use different personality functions.
> > 
> > I don't think so.  The IL should be still in a state where the inlined
> > pieces would simply inherit the callers personality.  But maybe I'm
> > missing something?
> 
> You're missing that the personality functions have to deal with
> the language's runtime types, as recorded in the catch type_list
> and the allowed-exceptions type_list.
> 
> You can't expect the Ada personality to deal with C++ runtime types.

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.

> > > Do you have a strategy for handling
> > > 
> > >    if (targetm.arm_eabi_unwinder)
> > >      unwind_resume_libfunc = init_one_libfunc ("__cxa_end_cleanup");
> > > 
> > > since this function is only used for c++/java?
> > 
> > No.  Do you have something in mind?
> 
> 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?

> > I see the patch is somewhat incomplete (there's also
> > lang_eh_runtime_type, but maybe we never call add_type_for_runtime
> > after a frontend finishes - in which case this should have been
> > a langhook?) - and in general the integration of EH aware and
> > non-EH aware code with LTO still needs work and thought.
> 
> We do all the calls to add_type_for_runtime during
> pass_lower_eh, right toward the beginning of compilation.
> I'm pretty sure we don't need to do anything else with
> that lang hook for LTO.

Ok.  I'll modify the patch to make this a true langhook and maybe move
the eh-personality also to a langhook called from eh lowering.

How does that sound?

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]