public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/97194] optimize vector element set/extract at variable position
Date: Mon, 28 Sep 2020 09:20:27 +0000 [thread overview]
Message-ID: <bug-97194-4-x5gdjXFgrH@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97194-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #7)
> FWIW, Peter Cordes provides an overview of available approaches for
> extraction depending on vector length and ISA extensions (up to AVX2, not
> including AVX-512) in this StackOverflow answer:
> https://stackoverflow.com/a/51414330/4755075
>
> TL;DR: generally through store+load; possible alternatives:
> 128b:
> SSSE3: pshufb (1-byte elements)
> SSSE3: imul+add+pshufb (any element size)
> AVX: vpermilp[sd] (4 or 8-byte elements)
> 256b:
> AVX2: vpermps (4-byte elements)
>
> In all cases a (v)movd is needed to move the index to a vector register, and
> potentially another (v)movd if the result is needed in a general register.
>
> The basic store+load tactic may look worse latency-wise, but can be better
> throughput-wise (especially with multiple extractions from the same vector,
> as then the store needs to be done just once, as Peter mentioned).
>
> Why in RTL it is important to do this without referencing the stack?
For extraction it isn't absolutely required to do this w/o the stack
since the spill would cover the whole vector and the reads can be
usually handled with store-forwarding in the CPUs. So here this
can be fully based on cost.
The insert case is instead very bad here with a whole-vector store
followed by an element store and then a whole-vector load. This
sequence will usually cause at least additional latency or worse
recovering from a bad store-forwarding.
Note that currently RTL expansion forces a local vector typed variable
to the stack (instead of allocating a pseudo) when there are
variable-index accesses to it. That might be a reason to also handle
slightly "expensive" extract cases. But I guess later falling back
to a stack slot via a splitter or LRA will lead to worse code.
next prev parent reply other threads:[~2020-09-28 9:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 14:26 [Bug target/97194] New: " rguenth at gcc dot gnu.org
2020-09-24 14:27 ` [Bug target/97194] " rguenth at gcc dot gnu.org
2020-09-24 14:39 ` rguenth at gcc dot gnu.org
2020-09-24 14:52 ` rguenth at gcc dot gnu.org
2020-09-25 6:47 ` rguenth at gcc dot gnu.org
2020-09-27 9:27 ` crazylht at gmail dot com
2020-09-28 7:01 ` rguenth at gcc dot gnu.org
2020-09-28 8:55 ` amonakov at gcc dot gnu.org
2020-09-28 9:20 ` rguenth at gcc dot gnu.org [this message]
2020-09-28 10:45 ` amonakov at gcc dot gnu.org
2020-09-28 11:10 ` rguenther at suse dot de
2020-09-28 11:19 ` amonakov at gcc dot gnu.org
2020-09-28 11:42 ` rguenth at gcc dot gnu.org
2020-09-28 11:44 ` rguenth at gcc dot gnu.org
2020-09-28 13:20 ` amonakov at gcc dot gnu.org
2020-10-16 7:17 ` crazylht at gmail dot com
2020-10-16 7:23 ` crazylht at gmail dot com
2020-10-16 7:31 ` rguenth at gcc dot gnu.org
2020-10-16 7:32 ` rguenth at gcc dot gnu.org
2020-10-16 7:46 ` crazylht at gmail dot com
2020-10-16 7:49 ` crazylht at gmail dot com
2020-10-16 8:03 ` rguenther at suse dot de
2020-11-17 3:31 ` cvs-commit at gcc dot gnu.org
2020-11-17 3:39 ` crazylht at gmail dot com
2021-06-17 13:20 ` cvs-commit at gcc dot gnu.org
2021-07-06 17:28 ` cvs-commit at gcc dot gnu.org
2022-01-11 12:05 ` 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-97194-4-x5gdjXFgrH@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).