[X86] Suboptimal code for storing double to global (trunk regression)

[davidbolvansky]

double a[64], b[64];

void foo (int k)
{
   a[k] += b[k];
}

LLVM trunk:

foo:                                    # @foo
        movsxd  rax, edi
        lea     rcx, [rip + b]
        movsd   xmm0, qword ptr [rcx + 8*rax]   # xmm0 = mem[0],zero
        lea     rcx, [rip + a]
        addsd   xmm0, qword ptr [rcx + 8*rax]
        movsd   qword ptr [rcx + 8*rax], xmm0
        ret
b:
        .zero   512

a:
        .zero   512

GCC/ICX/LLVM 14

foo:                                    # 
        movsxd  rax, edi
        movsd   xmm0, qword ptr [8*rax + a]     # xmm0 = mem[0],zero
        addsd   xmm0, qword ptr [8*rax + b]
        movsd   qword ptr [8*rax + a], xmm0
        ret
b:
        .zero   512

a:
        .zero   512

https://godbolt.org/z/15nMMKGof

Possible caused by opaque pointers? cc @nikic

[llvmbot]

@llvm/issue-subscribers-backend-x86

[topperc]

Not opaque pointers. It was caused by the change to default to -fpie. https://reviews.llvm.org/D120305

[topperc]

See also #56742

[MaskRay]

This is not a regression. This is just a -fno-pic vs -fpie code generation difference.
(Some Linux distributions patch their Clang to default to PIE before https://reviews.llvm.org/D120305)

Without PIC, in the small code model, a and b can fit into the 32-bit displacement.

With PIC, the addresses of a and b are not link-time constants. The code sequence has to take care of the run-time address. At run-time, due to ASLR, the addresses of a and b do not fit into 32-bit so we cannot use the displacement anyway (i.e. we cannot even use text relocations).

GCC -fpie has a similar codegen:

        movslq  %edi, %rdi
        leaq    a(%rip), %rax
        leaq    b(%rip), %rdx
        movsd   (%rax,%rdi,8), %xmm0
        addsd   (%rdx,%rdi,8), %xmm0
        movsd   %xmm0, (%rax,%rdi,8)

[davidbolvansky]

You patch mentions that “this matches gcc” but codegen of clang and gcc is different here… so gcc does no default to -fpie

[MaskRay]

You patch mentions that “this matches gcc” but codegen of clang and gcc is different here…

It's a somewhat unfortunate issue in GCC. While the GCC upstream default stays with no-pic for Linux target triples (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398), all Linux distributions I know (including a lot of GCC build scripts like glibc's scripts/build-many-glibcs.py) I know have switched to default PIE...

[davidbolvansky]

Ah, ok, thanks for info.

[MaskRay]

https://godbolt.org/ doesn't appear to use default PIE, which might be the source of confusion.
Filed compiler-explorer/gcc-cross-builder#33