From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24720 invoked by alias); 22 Oct 2014 11:40:30 -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 24711 invoked by uid 89); 22 Oct 2014 11:40:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 22 Oct 2014 11:40:28 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MBePUO028501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 07:40:26 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MBeM92001335 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Oct 2014 07:40:24 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9MBeLPb015272; Wed, 22 Oct 2014 13:40:21 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9MBeKqS015271; Wed, 22 Oct 2014 13:40:20 +0200 Date: Wed, 22 Oct 2014 11:43:00 -0000 From: Jakub Jelinek To: Kirill Yukhin Cc: Richard Biener , Uros Bizjak , Richard Henderson , GCC Patches Subject: Re: [PATCH i386 AVX512] [81/n] Add new built-ins. Message-ID: <20141022114020.GP10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20141020134122.GB12661@msticlxl57.ims.intel.com> <20141020135019.GP10376@tucnak.redhat.com> <20141021140805.GA22695@msticlxl57.ims.intel.com> <20141021142015.GY10376@tucnak.redhat.com> <20141021144749.GC22695@msticlxl57.ims.intel.com> <20141021150826.GD22695@msticlxl57.ims.intel.com> <20141022113420.GB11644@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141022113420.GB11644@msticlxl57.ims.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02236.txt.bz2 On Wed, Oct 22, 2014 at 03:34:22PM +0400, Kirill Yukhin wrote: > > Can you test with -mavx512 (or whatever enables the builtins?) > Done. > I did: > sync && time for i in `seq 1000` ; do ./build-x86_64-linux/gcc/xgcc -B./build-x86_64-linux/gcc -O0 -S test.c -mavx512vl ; done > > Here're results. > w/o the patch applied: > real 0m14.245s > user 0m10.753s > sys 0m2.150s > > w/ the patch applied: > real 0m16.404s > user 0m12.935s > sys 0m2.577s > > So, we have compilation 15% slowdown when -mavx512vl > is provided and no difference when not. > Is this change is acceptable? As #include enables everything these days, it will affect also that. I'd say the 15% slowdown for -mavx512vl and #include is not something that would preclude applying the patch, but definitely something to work on later on. Unfortunately, for the x86intrin.h case, lazy initialization of the builtins supposedly doesn't help at all, because pretty much all the builtins will be there. Jakub