From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4546 invoked by alias); 11 Jul 2009 17:59:52 -0000 Received: (qmail 4537 invoked by uid 22791); 11 Jul 2009 17:59:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Jul 2009 17:59:44 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id B909EF0621; Sat, 11 Jul 2009 19:59:40 +0200 (CEST) Date: Sat, 11 Jul 2009 17:59:00 -0000 From: Jan Hubicka To: Richard Henderson Cc: Jan Hubicka , jh@suse.cz, gcc@gcc.gnu.org Subject: Re: can_throw_internal affected by inlining? Message-ID: <20090711175940.GA8844@atrey.karlin.mff.cuni.cz> References: <4A57C772.7050509@redhat.com> <20090711125930.GB27815@atrey.karlin.mff.cuni.cz> <4A58CF89.9000502@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A58CF89.9000502@redhat.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00196.txt.bz2 > On 07/11/2009 05:59 AM, Jan Hubicka wrote: > >Well, we can either teach inlinable_call_p to handle your new indirect > >calls as "for sure uninlinable", make it conservative and consider all > >calls inlinable or we can stop doing the early removal of MUST_NOT_THROW > >receivers. > > I think this last option would probably be best. Something to work on > next week... It is easilly doable by making inlinable_call_p to return always true pre-inlining (even for non-calls). I can drop it to C++ testers so we can see how much memory/compile time overhad does this imply. I would like to bring more of EH lowering to tree level (i.e. instead of relying on RTL to lower RESX instructions into gotos/calls/jumptables do this at gimple and keep to RTL world only job of constructing landing pads). Then it might be nice to consider option to generate these in middle-end instead of preserving whatever frontend builds. The receivers are different for C++ and Java EH (calling std::terminate or abort) but otherwise there is nothing backend can't do. Currently we tend to end up with many std::terminate recerivers in single function that we should unify anyway. Honza > > > r~