From patchwork Mon Mar 17 08:39:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 330779 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 9E6F72C0086 for ; Mon, 17 Mar 2014 19:39:27 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=w4sBs5XdHC1jyrqjY qaHNPe7UtyTO37BPmiBsLZX68wH5TwIdyBQ1clSNGFJwt0bZyxqxOhr17h2avoYJ LIRJwNjQ7iWdjzHMz+sLw0VnnzjUThpFHoira+RLuejFXg8wn6/uDOkb7uF4RvCi TjvW7zGquYY/y0FNHgiPWNZbXA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=oto8HEnCVIFReoWgoelLLF5 Y3WE=; b=jNoy+V3ShYb8WDfKzWoCu4Kpu9ycibLHQxuXtQPExIO0b1hnNPEa5q0 UbjtvfnPzrSxQs5GasGaqu9YxRMW8husHDDzhnCvJynJ7QCdVPjczBn0ub0t+XC1 RxxdtMovYih66isFYmsUMAh/8egvOX9nXnMBlj65huLB2aas8fwE= Received: (qmail 3582 invoked by alias); 17 Mar 2014 08:39:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 3569 invoked by uid 89); 17 Mar 2014 08:39:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 17 Mar 2014 08:39:17 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id E0A89540DFD; Mon, 17 Mar 2014 09:39:13 +0100 (CET) Date: Mon, 17 Mar 2014 09:39:13 +0100 From: Jan Hubicka To: Jason Merrill Cc: gcc-patches List , Jan Hubicka Subject: Re: C++ PATCH for c++/58678 (devirt vs. KDE) Message-ID: <20140317083913.GF20522@kam.mff.cuni.cz> References: <5323528C.1080308@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5323528C.1080308@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) > Honza suggested that if the destructor for an abstract class can't > ever be called through the vtable, the front end could avoid > referring to it from the vtable. This patch replaces such a > destructor with __cxa_pure_virtual in the vtable. > > Tested x86_64-pc-linux-gnu, applying to trunk. Thank you! would preffer different marker than cxa_pure_virtual in the vtable, most probably simply NULL. The reason is that __cxa_pure_virtual will appear as a possible target in the list and it will prevent devirtualiztion to happen when we end up with __cxa_pure_virtual and real destructor in the list of possible targets. gimple_get_virt_method_for_vtable knows that lookup in vtable that do not result in FUNCTION_DECL should be translated to BUILTIN_UNREACHABLE and ipa-devirt drops these from list of targets, unlike __cxa_pure_virtual that stays. Other problem with cxa_pure_virtual is that it needs external relocation. I sort of wonedered if we don't want to produce hidden comdat wrapper for it, so C++ programs are easier to relocate. I will still keep the patch to mark ABSTACT classes by BINFO flag and will send out the patch I made to make ABSTRACT classes to be ignored for anonymous namespace types. It seems to make difference for libreoffice that uses a lot of abstracts. What do you think of the following patch that makes ipa-devirt to conclude that destructor calls are never done on types in construction. If effect of doing so is undefined, I think it is safe to drop them from list of targets and that really helps to reduce lists down. Index: ipa-devirt.c =================================================================== --- ipa-devirt.c (revision 208492) +++ ipa-devirt.c (working copy) @@ -1511,7 +1558,10 @@ possible_polymorphic_call_targets (tree target = NULL; } - maybe_record_node (nodes, target, inserted, can_refer, &complete); + /* Destructors are never called through construction virtual tables, + because the type is always known. */ + if (target && DECL_CXX_DESTRUCTOR_P (target)) + context.maybe_in_construction = false; if (target) {