[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 via 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)