[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

[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]

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)

[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

[pinskia at gcc dot gnu.org]

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.

[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

[crazylht at gmail dot com]

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

[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

[rguenth at gcc dot gnu.org]

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?

[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

[gabravier at gmail dot com]

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.