From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10411 invoked by alias); 9 Sep 2009 09:34:43 -0000 Received: (qmail 10348 invoked by uid 22791); 9 Sep 2009 09:34:42 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Sep 2009 09:34:37 +0000 Received: from relay2.suse.de (mail2.suse.de [195.135.221.8]) by mx2.suse.de (Postfix) with ESMTP id 9DF464844E; Wed, 9 Sep 2009 11:34:35 +0200 (CEST) Date: Wed, 09 Sep 2009 09:34:00 -0000 From: Richard Guenther To: Richard Henderson Cc: gcc-patches@gcc.gnu.org, Diego Novillo Subject: Re: [PATCH] Merge from LTO: eh_personality changes In-Reply-To: Message-ID: References: <4AA293E4.8090301@redhat.com> <4AA2A9D7.3030406@redhat.com> <4AA67CD1.8020602@redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00589.txt.bz2 On Tue, 8 Sep 2009, Richard Guenther wrote: > 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. As we need the information to decide inlining it would be at least an inconvenience to LTO to also read in (parts of) EH data in the IPA phase. So I'll leave that alone for now. Richard.