public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "husseydevin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/103641] New: [aarch64][11 regression] Severe compile time regression in SLP vectorize step
Date: Fri, 10 Dec 2021 09:03:15 +0000	[thread overview]
Message-ID: <bug-103641-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641

            Bug ID: 103641
           Summary: [aarch64][11 regression] Severe compile time
                    regression in SLP vectorize step
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: husseydevin at gmail dot com
  Target Milestone: ---

Created attachment 51966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51966&action=edit
aarch64-linux-gnu-gcc-11 -O3 -c xxhash.c -ftime-report -ftime-report-details

While GCC 11.2 has been noticably better at NEON64 code, with some files it
hangs for more than 15-30 seconds on the SLP vectorization step.

I haven't narrowed this down to a specific thing yet because I don't know much
about the GCC internals, but it is *extremely* noticeable in the xxHash
library. (https://github.com/Cyan4973/xxHash).

This is a test compiling xxhash.c from Git revision
a17161efb1d2de151857277628678b0e0b486155.

This was done on a Core i5-430m with 8GB RAM and an SSD on Debian Bullseye
amd64. GCC 10 (10.2.1-6) was from the\repos, GCC 11 (11.2.0) was built from the
tarball with similar flags. While this may cause bias, the two compilers get
very similar times when the SLP vectorizer is off.

$ time aarch64-linux-gnu-gcc-10 -O3 -c xxhash.c

real    0m3.596s
user    0m3.270s
sys     0m0.149s
$ time aarch64-linux-gnu-gcc-11 -O3 -c xxhash.c

real    0m31.579s
user    0m31.314s
sys     0m0.112s

When disabling the NEON intrinsics with `-DXXH_VECTOR=0`, it only takes ~21
seconds. 

Time variable                                   usr           sys          wall
          GGC
 phase opt and generate             :  31.46 ( 97%)   0.24 ( 32%)  31.80 ( 96%)
   54M ( 63%)
 callgraph functions expansion      :  31.01 ( 96%)   0.18 ( 24%)  31.29 ( 94%)
   42M ( 49%)
 tree slp vectorization             :  28.35 ( 88%)   0.03 (  4%)  28.37 ( 85%)
 9941k ( 11%)

 TOTAL                              :  32.34          0.75         33.20       
   86M

This is significantly worse on my Pi 4B, where an ARMv7->AArch64 build took 3
minutes, although I presume that is mostly due to being 32-bit and the CPU
being much slower.

             reply	other threads:[~2021-12-10  9:03 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10  9:03 husseydevin at gmail dot com [this message]
2021-12-10  9:25 ` [Bug rtl-optimization/103641] " marxin at gcc dot gnu.org
2021-12-10  9:37 ` [Bug tree-optimization/103641] " pinskia at gcc dot gnu.org
2021-12-10  9:43 ` [Bug tree-optimization/103641] [11/12 " pinskia at gcc dot gnu.org
2021-12-10  9:46 ` pinskia at gcc dot gnu.org
2021-12-10  9:56 ` pinskia at gcc dot gnu.org
2021-12-10 10:01 ` marxin at gcc dot gnu.org
2021-12-10 10:02 ` pinskia at gcc dot gnu.org
2021-12-10 10:03 ` pinskia at gcc dot gnu.org
2021-12-10 10:06 ` marxin at gcc dot gnu.org
2021-12-10 10:08 ` pinskia at gcc dot gnu.org
2021-12-10 10:09 ` pinskia at gcc dot gnu.org
2021-12-10 10:12 ` marxin at gcc dot gnu.org
2021-12-10 10:12 ` pinskia at gcc dot gnu.org
2021-12-10 10:14 ` pinskia at gcc dot gnu.org
2021-12-10 10:15 ` [Bug middle-end/103641] " pinskia at gcc dot gnu.org
2021-12-10 10:24 ` pinskia at gcc dot gnu.org
2021-12-10 10:28 ` pinskia at gcc dot gnu.org
2021-12-10 13:17 ` roger at nextmovesoftware dot com
2021-12-10 13:19 ` husseydevin at gmail dot com
2022-01-18 14:10 ` rguenth at gcc dot gnu.org
2022-01-22 14:30 ` roger at nextmovesoftware dot com
2022-01-24  8:13 ` rguenther at suse dot de
2022-01-24 16:49 ` roger at nextmovesoftware dot com
2022-01-24 17:02 ` roger at nextmovesoftware dot com
2022-01-25  7:23 ` rguenth at gcc dot gnu.org
2022-01-25  7:52 ` rguenth at gcc dot gnu.org
2022-02-04  7:26 ` rguenth at gcc dot gnu.org
2022-02-04 10:30 ` cvs-commit at gcc dot gnu.org
2022-02-04 10:43 ` rguenth at gcc dot gnu.org
2022-02-04 11:08 ` tnfchris at gcc dot gnu.org
2022-02-07 12:19 ` tnfchris at gcc dot gnu.org
2022-02-07 15:05 ` [Bug middle-end/103641] [11 " rguenth at gcc dot gnu.org
2022-02-08  8:08 ` tnfchris at gcc dot gnu.org
2022-02-08  8:13 ` pinskia at gcc dot gnu.org
2022-02-08  8:15 ` tnfchris at gcc dot gnu.org
2022-03-16  8:22 ` cvs-commit at gcc dot gnu.org
2022-03-16  8:23 ` rguenth at gcc dot gnu.org

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=bug-103641-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).