public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/95962] Inefficient code for simple arm_neon.h iota operation
Date: Fri, 20 Aug 2021 11:52:08 +0000 [thread overview]
Message-ID: <bug-95962-4-uRcuyoL1QF@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-95962-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #1)
> We generate the correct code at -O3 but not -O2.
>
> At -O3 we generate
>
> foo:
> adrp x0, .LC0
> sub sp, sp, #16
> ldr q0, [x0, #:lo12:.LC0]
> add sp, sp, 16
> ret
>
> where the problem seems to be at at -O2 store merging has broken up the
> construction of `array` into two separate memory accesses:
>
> MEM <unsigned long> [(int *)&array] = 4294967296;
> MEM <unsigned long> [(int *)&array + 8B] = 12884901890;
>
> whereas at -O3 we still have a single assignment:
>
> MEM <vector(4) int> [(int *)&array] = { 0, 1, 2, 3 };
>
> I'm not sure even if we made these loads gimple level if that would help.
> we'd still have the explicit MEMs created by store merging.
If we folded them to gimple loads, the gimple optimisers should replace
the MEM with an assignment of the VECTOR_CST { 0, 1, 2, 3 } to an SSA name,
with the function returning the SSA name.
expand will convert this back into a memory access, in the form of
an RTL constant pool load. But that will avoid the stack temporary
and thus the pointless stack adjustments.
next prev parent reply other threads:[~2021-08-20 11:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 12:49 [Bug target/95962] New: " rsandifo at gcc dot gnu.org
2021-08-12 8:01 ` [Bug target/95962] " tnfchris at gcc dot gnu.org
2021-08-20 11:52 ` rsandifo at gcc dot gnu.org [this message]
2021-11-15 15:09 ` tnfchris at gcc dot gnu.org
2021-12-03 17:05 ` rsandifo 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-95962-4-uRcuyoL1QF@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).