From patchwork Fri May 23 10:03:37 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 351791 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 9ACAC14009C for ; Fri, 23 May 2014 20:03:52 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=pj/Nc6hM7RWeYbQ2rw CFhLFqtqn8ZAT099FYaZs8jOL3RGKAQEAUrto+Fu/5OcL6vjJKSmBoz9IFwtmIgg NIF1qF4mML60kKGX3foQ2qzpIBlQiorWiU2HG9bRnHev4NLtEdNXshWaIkX2frM3 VrEiyty5kxdPDvBwnsCMxq52E= 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 :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=s0YYRp3Yvdv+t9uGf/3uwdhN 0RM=; b=BZ04s5kJNvH3RMpJqDY3uElgNgVfEN8Ydn7Lvz3wyDtaCdhZEduRpCyB 2Nd7Vfc8bekiOwgjEspe+cBPtecT8oob7t+7G3kp92dFi70T47JoaZodkry7blYz 9TqHmmcHmQn1ehUYinnWhRqh0kTcaWHUGoPS0iG1JdPnaH5M1VI= Received: (qmail 28537 invoked by alias); 23 May 2014 10:03:43 -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 28461 invoked by uid 89); 23 May 2014 10:03:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f177.google.com Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com) (74.125.82.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 23 May 2014 10:03:41 +0000 Received: by mail-we0-f177.google.com with SMTP id x48so4553808wes.22 for ; Fri, 23 May 2014 03:03:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.225 with SMTP id l1mr3202913wjq.25.1400839417867; Fri, 23 May 2014 03:03:37 -0700 (PDT) Received: by 10.194.119.193 with HTTP; Fri, 23 May 2014 03:03:37 -0700 (PDT) In-Reply-To: <20140522181130.GA10913@atrey.karlin.mff.cuni.cz> References: <20140521131634.178838544@virgil.suse.cz> <20140521131634.646352575@virgil.suse.cz> <20140522124952.GA13095@virgil.suse> <20140522152433.GB19612@kam.mff.cuni.cz> <20140522181130.GA10913@atrey.karlin.mff.cuni.cz> Date: Fri, 23 May 2014 12:03:37 +0200 Message-ID: Subject: Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags From: Richard Biener To: Jan Hubicka Cc: GCC Patches X-IsSubscribed: yes On Thu, May 22, 2014 at 8:11 PM, Jan Hubicka wrote: >> >It won't be so easy, because struct function is really built at >> >relatively convoluted >> >places within frontend before cgraph node is assigned to them (I tried >> >that few years >> >back). >> >> Well, just call cgraph create node from struct Funktion allocation. > > That will make uninstantiated templates to land symbol table (and if you have > aliases, also do the assembler name mangling) that is not that cool either :( Well, allocate_struct_function has a abstract_p argument for that. But yes, a simple patch like ICEs during bootstrap with (at least) /space/rguenther/src/svn/trunk/libgcc/config/i386/cpuinfo.c:405:1: error: node differs from symtab decl hashtable } ^ __get_cpuid_max.constprop.0/42 (__get_cpuid_max.constprop) @0x7ff486232290 Type: function definition analyzed Visibility: artificial previous sharing asm name: 43 References: Referring: Function __get_cpuid_max.constprop/42 is inline copy in __get_cpuid_output/40 Availability: local First run: 0 Function flags: local only_called_at_startup Called by: __get_cpuid_output/40 (1.00 per call) (inlined) Calls: /space/rguenther/src/svn/trunk/libgcc/config/i386/cpuinfo.c:405:1: internal compiler error: verify_cgraph_node failed so I guess we would need to have a way to create a "dummy" cgraph node first and later populate it properly. But as we currently have a back-pointer from struct function to fndecl it would be nice to hook the cgraph node in there - that way we get away without any extra pointer (we could even save symtab decl pointer and create a cyclic fndecl -> cgraph -> function -> fndecl chain ...). I'm fine with enlarging tree_function_decl for now - ideally we'd push stuff from it elsewhere (like target and optimization option tree nodes, or most of the visibility and symbol related stuff). Not sure why tree_type_decl inherits from tree_decl_non_common (and thus tree_decl_with_vis). Probably because of the non-common parts being (ab-)used by FEs. Otherwise I'd say simply put a symtab node pointer into tree_decl_with_vis ... (can we move section_name and comdat_group more easily than assembler_name?) Richard. > Honza >> >> Richard. >> >> >I think we may be on better track moving DECL_ASSEMBLER_NAME that is >> >calculated later, >> >but then we have problem with DECL_ASSEMBLER_NAME being set for >> >assembler names and >> >const decls, too that still go around symtab. >> >Given that decl_assembler_name is a function, I suppose we could go >> >with extra conditoinal >> >in there. >> > >> >Getting struct function out of frontend busyness would be nice indeed, >> >too, but probably >> >should be independent of Martin's work here. >> > >> >Honza >> >> >> >> Thanks, >> >> Richard. >> >> >> >> > Thanks, >> >> > >> >> > Martin >> >> > >> >> >> >> >> >> > + } >> >> >> > } >> >> >> > + >> >> >> > + return ret; >> >> >> > } >> >> >> > >> >> >> > /* Detects return flags for the call STMT. */ >> >> >> > >> Index: gcc/function.c =================================================================== --- gcc/function.c (revision 210845) +++ gcc/function.c (working copy) @@ -64,6 +64,7 @@ along with GCC; see the file COPYING3. #include "params.h" #include "bb-reorder.h" #include "shrink-wrap.h" +#include "cgraph.h" /* So we can assign to cfun in this file. */ #undef cfun @@ -4512,6 +4513,8 @@ allocate_struct_function (tree fndecl, b if (fndecl != NULL_TREE) { + if (!abstract_p) + cgraph_get_create_node (fndecl); DECL_STRUCT_FUNCTION (fndecl) = cfun; cfun->decl = fndecl; current_function_funcdef_no = get_next_funcdef_no ();