From: Jakub Jelinek <jakub@redhat.com>
To: Kirill Yukhin <kirill.yukhin@gmail.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
Uros Bizjak <ubizjak@gmail.com>,
Richard Henderson <rth@redhat.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH i386 AVX512] [81/n] Add new built-ins.
Date: Wed, 22 Oct 2014 11:43:00 -0000 [thread overview]
Message-ID: <20141022114020.GP10376@tucnak.redhat.com> (raw)
In-Reply-To: <20141022113420.GB11644@msticlxl57.ims.intel.com>
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 <x86intrin.h> enables everything these days,
it will affect also that.
I'd say the 15% slowdown for -mavx512vl and #include <x86intrin.h>
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
next prev parent reply other threads:[~2014-10-22 11:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 13:50 Kirill Yukhin
2014-10-20 13:56 ` Jakub Jelinek
2014-10-21 9:19 ` Richard Biener
2014-10-21 14:19 ` Kirill Yukhin
2014-10-21 14:09 ` Kirill Yukhin
2014-10-21 14:21 ` Jakub Jelinek
2014-10-21 14:52 ` Kirill Yukhin
2014-10-21 15:13 ` Kirill Yukhin
2014-10-22 8:18 ` Richard Biener
2014-10-22 11:40 ` Kirill Yukhin
2014-10-22 11:43 ` Jakub Jelinek [this message]
2014-10-22 7:57 ` [PATCH AVX512] [81.1/n] Extend `function_code' field in `tree_var_decl' structure Kirill Yukhin
2014-10-23 11:10 ` Jakub Jelinek
2014-10-21 14:24 ` [PATCH i386 AVX512] [81/n] Add new built-ins Richard Biener
2014-10-23 12:58 ` [PATCH i386 AVX512] [81.2/n] " Kirill Yukhin
2014-10-23 13:46 ` Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141022114020.GP10376@tucnak.redhat.com \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kirill.yukhin@gmail.com \
--cc=richard.guenther@gmail.com \
--cc=rth@redhat.com \
--cc=ubizjak@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).