From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7593 invoked by alias); 20 Mar 2012 14:12:21 -0000 Received: (qmail 7576 invoked by uid 22791); 20 Mar 2012 14:12:19 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Mar 2012 14:11:55 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 91BBC29003C; Tue, 20 Mar 2012 15:11:56 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdgsfJpMRhn1; Tue, 20 Mar 2012 15:11:56 +0100 (CET) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 79E6D290006; Tue, 20 Mar 2012 15:11:56 +0100 (CET) Subject: Re: [Patch/cfgexpand]: also consider assembler_name to call expand_main_function Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tristan Gingold In-Reply-To: Date: Tue, 20 Mar 2012 14:12:00 -0000 Cc: GCC Patches , Eric Botcazou , Jan Hubicka Content-Transfer-Encoding: quoted-printable Message-Id: <20FDC949-4630-403F-94E9-7F75B6E5E120@adacore.com> References: <875C6F56-7161-48DF-91FB-3A01891F8289@adacore.com> <6BCCAF3B-005E-449E-917C-4B88B78F1946@adacore.com> To: Richard Guenther X-IsSubscribed: yes 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: 2012-03/txt/msg01353.txt.bz2 On Mar 20, 2012, at 1:21 PM, Richard Guenther wrote: > On Tue, 20 Mar 2012, Tristan Gingold wrote: >=20 >>=20 >> On Mar 15, 2012, at 10:37 AM, Richard Guenther wrote: >>=20 >>> On Wed, 14 Mar 2012, Tristan Gingold wrote: >> [=85] >>=20 >>>=20 >>> Well. To make this work in LTO the "main" function (thus, the program >>> entry point) should be marked at cgraph level and all users of >>> MAIN_NAME_P should instead check a flag on the cgraph node. >>>=20 >>>> Will write a predicate in tree.[ch]. >>>=20 >>> Please instead transition "main-ness" to the graph. >>=20 >> Hi, >>=20 >> here is the patch I wrote. Does it match what you had in mind ? >=20 > Basically yes. Comments below. >=20 >> main_identifier_node is now set in tree.c >=20 > Looks good, hopefully my review-grep was as good as yours ;) [=85] >> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c >> index bd21169..7a7a774 100644 >> --- a/gcc/cfgexpand.c >> +++ b/gcc/cfgexpand.c >> @@ -4513,9 +4513,8 @@ gimple_expand_cfg (void) >>=20 >> /* If this function is `main', emit a call to `__main' >> to run global initializers, etc. */ >> - if (DECL_NAME (current_function_decl) >> - && MAIN_NAME_P (DECL_NAME (current_function_decl)) >> - && DECL_FILE_SCOPE_P (current_function_decl)) >> + if (DECL_FILE_SCOPE_P (current_function_decl) >> + && cgraph_main_function_p (cgraph_get_node (current_function_decl= ))) >> expand_main_function (); >=20 > The DECL_FILE_SCOPE_P check is redundant, please remove them everywhere > you call cgraph_main_function_p. I suppose returning false if the > cgraph node is NULL in cgraph_main_function_p would be good. Ok. (I added the DECL_FILE_SCOPE_P check to avoid the cgraph lookup for sp= eed reason) [=85] >> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c >> index 516f187..4a59f63 100644 >> --- a/gcc/cgraphunit.c >> +++ b/gcc/cgraphunit.c >> @@ -346,6 +346,10 @@ cgraph_finalize_function (tree decl, bool nested) >> notice_global_symbol (decl); >> node->local.finalized =3D true; >> node->lowered =3D DECL_STRUCT_FUNCTION (decl)->cfg !=3D NULL; >> + node->local.main_function =3D >> + DECL_FILE_SCOPE_P (decl) >> + && ((!DECL_ASSEMBLER_NAME_SET_P (decl) && MAIN_NAME_P (DECL_NAME (d= ecl))) >> + || decl_assembler_name_equal (decl, main_identifier_node)); >=20 > If we finalize a function we should always create an assembler name, > thus I'd change the above to >=20 > node->local.main_function =3D decl_assembler_name_equal (decl,=20 > main_identifier_node); Indeed. At worst, the assembler name is created during the call to notice_= global_symbol. > btw, decl_assembler_name_equal doesn't seem to remove target-specific > mangling - do some OSes "mangle" main differently (I'm thinking of > leading underscores or complete renames)? Thus, I guess the > targets might want to be able to provide the main_identifier_assember_name > you use here. I think this is currently OK because decl_assembler_name_equal deals with leading underscore correctly. I have checked that on Darwin, which has a leading underscore. The only target that mangle names is i386 cygwin/mingw, which 'annotates' stdcall and fastcall function, but main() is regular. But I agree this mechanism is fragile. In order to make this mechanism stronger, we could add main_function_node, = which designates the FUNCTION_DECL that is the main function (if not NULL_TREE), = with a fallback on main_identifier_node for regular languages such as C or C++. Tristan.