public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hliu at amperecomputing dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large
Date: Wed, 12 Jul 2023 00:58:58 +0000	[thread overview]
Message-ID: <bug-110625-4-TAB0sPzsSZ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110625-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #2 from Hao Liu <hliu at amperecomputing dot com> ---
To my understanding, "reduction latency" is the least number of cycles needed
to do the reduction calculation for 1 iteration of loop.  It is calcualted by
the extra instruction issue-info of the new cost models in AArch64 backend.

Usually, the reduction latency of vectorized loop should be smaller than the
scalar loop.  If the latency of vectorized loop is larger than the scalar loop,
it thinks maybe not beneficial to do vectorization, so it increases the
vect-body costs by the scale of vect_reduct_latency/scalar_reduct_latency in
the above case.

For the above case, it thinks the scalar loop needs 4 cycles (2*VF=4) to
calculate "results.m += rhs", while the vectorized loop needs 8 cycles
(2*count=8).  As a result, the vect-body costs are doubled from originial value
of 51 to 102.  It seems not true for the vectorized loop, which should only
need 2 cycles to calculate the SIMD version of "results.m += rhs".

  parent reply	other threads:[~2023-07-12  0:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11  9:15 [Bug target/110625] New: " hliu at amperecomputing dot com
2023-07-11 10:41 ` [Bug target/110625] " rguenth at gcc dot gnu.org
2023-07-12  0:58 ` hliu at amperecomputing dot com [this message]
2023-07-14  8:58 ` hliu at amperecomputing dot com
2023-07-18 10:41 ` rsandifo at gcc dot gnu.org
2023-07-18 12:03 ` rsandifo at gcc dot gnu.org
2023-07-19  2:57 ` hliu at amperecomputing dot com
2023-07-19  8:55 ` rsandifo at gcc dot gnu.org
2023-07-19  9:36 ` hliu at amperecomputing dot com
2023-07-28 16:50 ` rsandifo at gcc dot gnu.org
2023-07-28 16:53 ` rsandifo at gcc dot gnu.org
2023-07-31  2:45 ` hliu at amperecomputing dot com
2023-07-31 12:56 ` cvs-commit at gcc dot gnu.org
2023-08-01  9:09 ` tnfchris at gcc dot gnu.org
2023-08-01  9:19 ` tnfchris at gcc dot gnu.org
2023-08-01  9:45 ` hliu at amperecomputing dot com
2023-08-01  9:49 ` tnfchris at gcc dot gnu.org
2023-08-01  9:50 ` hliu at amperecomputing dot com
2023-08-01 13:49 ` tnfchris at gcc dot gnu.org
2023-08-02  3:49 ` hliu at amperecomputing dot com
2023-08-04  2:34 ` cvs-commit at gcc dot gnu.org
2023-12-08 10:20 ` [Bug target/110625] [14 Regression][AArch64] " tnfchris at gcc dot gnu.org
2023-12-12 16:26 ` tnfchris at gcc dot gnu.org
2023-12-26 14:55 ` tnfchris at gcc dot gnu.org
2023-12-29 15:59 ` cvs-commit at gcc dot gnu.org
2023-12-29 16:16 ` tnfchris at gcc dot gnu.org
2023-12-30  8:34 ` hliu at amperecomputing dot com

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-110625-4-TAB0sPzsSZ@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).