From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26083 invoked by alias); 21 Oct 2014 14:48:17 -0000 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 Received: (qmail 26062 invoked by uid 89); 21 Oct 2014 14:48:16 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f43.google.com Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 21 Oct 2014 14:48:10 +0000 Received: by mail-wg0-f43.google.com with SMTP id m15so1590265wgh.14 for ; Tue, 21 Oct 2014 07:48:06 -0700 (PDT) X-Received: by 10.194.241.201 with SMTP id wk9mr43572021wjc.101.1413902885919; Tue, 21 Oct 2014 07:48:05 -0700 (PDT) Received: from msticlxl57.ims.intel.com (fmdmzpr04-ext.fm.intel.com. [192.55.55.39]) by mx.google.com with ESMTPSA id q5sm13328721wiy.16.2014.10.21.07.48.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 07:48:05 -0700 (PDT) Date: Tue, 21 Oct 2014 14:52:00 -0000 From: Kirill Yukhin To: Jakub Jelinek Cc: Uros Bizjak , Richard Henderson , GCC Patches Subject: Re: [PATCH i386 AVX512] [81/n] Add new built-ins. Message-ID: <20141021144749.GC22695@msticlxl57.ims.intel.com> References: <20141020134122.GB12661@msticlxl57.ims.intel.com> <20141020135019.GP10376@tucnak.redhat.com> <20141021140805.GA22695@msticlxl57.ims.intel.com> <20141021142015.GY10376@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141021142015.GY10376@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02094.txt.bz2 On 21 Oct 16:20, Jakub Jelinek wrote: > On Tue, Oct 21, 2014 at 06:08:15PM +0400, Kirill Yukhin wrote: > > --- a/gcc/tree.h > > +++ b/gcc/tree.h > > @@ -2334,6 +2334,10 @@ extern void decl_value_expr_insert (tree, tree); > > #define DECL_COMDAT(NODE) \ > > (DECL_WITH_VIS_CHECK (NODE)->decl_with_vis.comdat_flag) > > > > + /* In a FUNCTION_DECL indicates that a static chain is needed. */ > > +#define DECL_STATIC_CHAIN(NODE) \ > > + (DECL_WITH_VIS_CHECK (NODE)->decl_with_vis.regdecl_flag) > > + > > I would say that you should still keep it together with the FUNCTION_DECL > macros and use FUNCTION_DECL_CHECK there, to make it clear we don't want > the macro to be used on VAR_DECLs etc. > So just s/function_decl/decl_with_vis/ in the definition IMHO. Yeah, sure. > Also, with so many added builtins, how does it affect > int i; > compilation time at -O0? If it is significant, maybe it is highest time to > make the md builtin decl building more lazy. I've tried this: $ echo "int i;" > test.c $ time for i in `seq 10000` ; do ./build-x86_64-linux/gcc/xgcc -B./build-x86_64-linux/gcc -O0 -S test.c ; done For trunk w/ and w/o the patch applied. Got 106.86 vs. 106.85 secs. which looks equal. So, I think we may say that this patch does not affect compile time. -- Thanks, K > > Jakub