inefficient segment register relative access

[nickdesaulniers]

consider the following code:

// -fstack-protector-strong -O2 -mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=__stack_chk_guard -fno-pie
void foo (int*);

void bar (int x) {
    int y [x];
    foo(y);
}

clang generates:

        movq    __stack_chk_guard@GOTPCREL(%rip), %rbx
        movq    %gs:(%rbx), %rax
        movq    %rax, -16(%rbp)

to read the stack canary into the relevant stack slot. GCC generates a much nicer:

        movq    %gs:__stack_chk_guard(%rip), %rax
        movq    %rax, -8(%rbp)

Can we do better? (15B vs 12B per function with a stack protector)

[llvmbot]

@llvm/issue-subscribers-backend-x86

[nickdesaulniers]

This looks fixed by @MaskRay 's https://reviews.llvm.org/D150841 (was that intentional)? (without specifying -f[no-]direct-access-external-data).

	movq	%gs:__stack_chk_guard(%rip), %rax
	movq	%rax, -8(%rbp)

[MaskRay]

Duplicate of #60116

(-fstack-protector-strong -fno-PIE -mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=__stack_chk_guard)

Clang's GOT-indirect code sequence for no-PIC avoids a copy relocation if __stack_chk_guard turns out to be defined by a shared object (say, libc.so.6).