public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Jason Mancini <jayrusman@hotmail.com>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
Date: Tue, 23 Apr 2019 12:58:00 -0000	[thread overview]
Message-ID: <CAH6eHdR21jqudEDns2VEdsTiZ5N1Yo2cTiamrnOBfu35weMdgQ@mail.gmail.com> (raw)
In-Reply-To: <BYAPR06MB4710615E1AD392D683470262AB230@BYAPR06MB4710.namprd06.prod.outlook.com>

On Tue, 23 Apr 2019 at 01:18, Jason Mancini <jayrusman@hotmail.com> wrote:
>
> We've determined that the gcc perf drop is due to use of decltype(auto) as the return type for template functions.  Replacing with a known type or func(...) -> decltype(...) trailing type syntax seems to avoid the performance issue.

Is the code you're compiling the same in all cases, meaning
decltype(auto) is faster with GCC 6 than later releases?

Or are you only using decltype(auto) with the later releases?

It's possible that GCC 7 and later fixes some bugs in the handling of
decltype(auto) which makes it slower than GCC 6.

It's unsurprising that decltype(auto) requires the compiler to do more
work, but ideally that work wouldn't make compilation exponentially
slower, even with less buggy behaviour than in older releases.

  reply	other threads:[~2019-04-23 12:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17  0:28 Jason Mancini
2019-04-17  2:10 ` Jason Mancini
2019-04-17  2:20   ` Xi Ruoyao
2019-04-17  8:38     ` Jonathan Wakely
2019-04-17  9:07       ` Segher Boessenkool
2019-04-18 16:06       ` Jason Mancini
2019-04-18 19:07         ` Segher Boessenkool
2019-04-18 19:38           ` Jeff Law
2019-04-19  2:03             ` Jason Mancini
2019-04-22 22:01             ` Jason Mancini
2019-04-22 22:17               ` Jason Mancini
2019-04-23  0:18             ` Jason Mancini
2019-04-23 12:58               ` Jonathan Wakely [this message]
2019-04-29 20:33               ` Jason Mancini
2019-05-01 13:31                 ` C11, <stdatomic.h> and atomic pointers Chris Hall
2019-05-01 14:15                   ` Martin Sebor
2019-05-02  7:54                     ` Jonathan Wakely
2019-06-20 11:28                   ` __STDC_NO_THREADS__ and late model gcc/glibc Chris Hall
2019-06-20 12:17                     ` Jonathan Wakely
2019-06-21  9:39                       ` Chris Hall
2019-06-21  9:51                         ` Jonathan Wakely
2020-01-06 15:09                     ` Function returning struct on x86_64 (at least) Chris Hall
2020-01-06 15:19                       ` Marc Glisse
2020-01-07 16:20                         ` Chris Hall

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=CAH6eHdR21jqudEDns2VEdsTiZ5N1Yo2cTiamrnOBfu35weMdgQ@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jayrusman@hotmail.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).