public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/100931] New: [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant
@ 2021-06-06 14:07 gabravier at gmail dot com
2021-06-06 20:21 ` [Bug target/100931] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: gabravier at gmail dot com @ 2021-06-06 14:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
Bug ID: 100931
Summary: [x86-64] Failure to optimize 2 32-bit stores converted
to a 64-bit store into using movabs instead of loading
from a constant
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void g(int *p) {
*p = 2;
p[1] = 2;
}
void h(long long *p)
{
*p = 0x200000002;
}
g compiles to this on GCC on plenty of architectures:
g(int*):
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rdi], rax
ret
.LC0:
.long 2
.long 2
h is equivalent to g (non-withstanding aliasing) and instead compiles to this:
h(long long*):
movabs rax, 8589934594
mov QWORD PTR [rdi], rax
ret
g has been compiled differently from h since GCC 10.
I'm somewhat doubtful about filing this bug actually, I personally think that h
will be faster and that g is simply a regression from GCC 9, but I can't really
be sure there isn't some architecture-specific reasoning to use a separate
constant, especially since this transformation seems to only occur on specific
architectures (generic, core2, nehalem, westmere, sandybridge, ivybridge,
haswell, broadwell, znver1, znver2 and znver3)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/100931] [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant
2021-06-06 14:07 [Bug target/100931] New: [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant gabravier at gmail dot com
@ 2021-06-06 20:21 ` pinskia at gcc dot gnu.org
2021-06-07 3:24 ` crazylht at gmail dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-06-06 20:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
SLP is happening.
This is just a cost model issue as -mtune=intel works.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/100931] [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant
2021-06-06 14:07 [Bug target/100931] New: [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant gabravier at gmail dot com
2021-06-06 20:21 ` [Bug target/100931] " pinskia at gcc dot gnu.org
@ 2021-06-07 3:24 ` crazylht at gmail dot com
2021-06-07 10:27 ` rguenth at gcc dot gnu.org
2021-06-07 10:40 ` gabravier at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: crazylht at gmail dot com @ 2021-06-07 3:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
Hongtao.liu <crazylht at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |crazylht at gmail dot com
--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
What's the option do you use?
with -O2 -march=x86-64, gcc generate same asm for g and h
https://godbolt.org/z/Wx5eG39aG
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/100931] [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant
2021-06-06 14:07 [Bug target/100931] New: [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant gabravier at gmail dot com
2021-06-06 20:21 ` [Bug target/100931] " pinskia at gcc dot gnu.org
2021-06-07 3:24 ` crazylht at gmail dot com
@ 2021-06-07 10:27 ` rguenth at gcc dot gnu.org
2021-06-07 10:40 ` gabravier at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-06-07 10:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suppose this is still an expander/backend missed optimization which doesn't
consider doing a V2SImode store in DImode?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/100931] [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant
2021-06-06 14:07 [Bug target/100931] New: [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant gabravier at gmail dot com
` (2 preceding siblings ...)
2021-06-07 10:27 ` rguenth at gcc dot gnu.org
@ 2021-06-07 10:40 ` gabravier at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: gabravier at gmail dot com @ 2021-06-07 10:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
--- Comment #4 from Gabriel Ravier <gabravier at gmail dot com> ---
Ah sorry for not clarifying. I get this bug for `-O3 -mtune=x` where x is one
of generic, core2, nehalem, westmere, sandybridge, ivybridge, haswell,
broadwell, znver1, znver2 and znver3. I have checked all other
micro-architectures and the bug did not occur on any of them.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-07 10:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-06 14:07 [Bug target/100931] New: [x86-64] Failure to optimize 2 32-bit stores converted to a 64-bit store into using movabs instead of loading from a constant gabravier at gmail dot com
2021-06-06 20:21 ` [Bug target/100931] " pinskia at gcc dot gnu.org
2021-06-07 3:24 ` crazylht at gmail dot com
2021-06-07 10:27 ` rguenth at gcc dot gnu.org
2021-06-07 10:40 ` gabravier at gmail dot com
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).