[X86][ELF] Prefer lowering MC_GlobalAddress operands to .Lfoo$local only for STV_DEFAULT globals

[bd1976llvm]

Summary

This patch restricts the behaviour of referencing via .Lfoo$local local aliases, introduced in https://reviews.llvm.org/D73230, to STV_DEFAULT globals only.

Hidden symbols via -fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility) is an important scenario.

Benefits:

• Improves the size of object files by using fewer STT_SECTION symbols.
• The code reads a bit better (it was not obvious to me without going back to the code reviews why the canBenefitFromLocalAlias function currently doesn't consider visibility).

There is also a side benefit in restoring the effectiveness of the --wrap linker option and making the behavior of --wrap consistent between LTO and normal builds for references within a translation-unit. Note: this --wrap behaviour (which is specific to LLD) should not be considered reliable. See comments on https://reviews.llvm.org/D73230 for more.

[MaskRay]

The additional test file places too much burden on people maintaining the tests in the future. I think an additional @hidden_data = hidden global in CodeGen/X86/linux-preemption.ll should be sufficient.

GNU now recommends -fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility) so my understanding is that there will be very few STV_DEFAULT symbols.

I am not very sure this is now recommended but is indeed a non-rare configuration we should care about.

Improves the assembly (as there are fewer .Lfoo$local labels).

There are still plenty of cases with the .Lfoo$local. I'd not state this advantage explicitly in this case.

Restores the effectiveness of the --wrap linker option and makes the behavior of --wrap consistent between LTO and normal builds for references within a translation-unit.

I think we should explicitly call out that this is still brittle. It is just a side benefit. (I know for you it is a major thing but I hope we don't give us false impression that this is reliably supported.) The main thing is the .symtab saving.

(My disagreement about advertising --wrap as an advantage does not mean that I'd unnecessarily break this - I think this will be sufficient robust - despite the brittle --wrap setup; and I'd pay attention for this case when improving/refactoring --wrap in LLD to not cause you additional trouble)

Also state that the --wrap behavior is specific to LLD.

[bd1976llvm]

In D85782#2211636, @MaskRay wrote:

The additional test file places too much burden on people maintaining the tests in the future. I think an additional @hidden_data = hidden global in CodeGen/X86/linux-preemption.ll should be sufficient.

Ok. Great! Unfortunately, I do think that the expansion of the elf-code-model testing is necessary at some point. The current test is only for PIE which constrains the codegen.

GNU now recommends -fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility) so my understanding is that there will be very few STV_DEFAULT symbols.

I am not very sure this is now recommended but is indeed a non-rare configuration we should care about.

Agreed. Recommended is probably too strong.

Improves the assembly (as there are fewer .Lfoo$local labels).

There are still plenty of cases with the .Lfoo$local. I'd not state this advantage explicitly in this case.

No problem - this is a minor benefit anyway.

Restores the effectiveness of the --wrap linker option and makes the behavior of --wrap consistent between LTO and normal builds for references within a translation-unit.

I think we should explicitly call out that this is still brittle. It is just a side benefit. (I know for you it is a major thing but I hope we don't give us false impression that this is reliably supported.) The main thing is the .symtab saving.

(My disagreement about advertising --wrap as an advantage does not mean that I'd unnecessarily break this - I think this will be sufficient robust - despite the brittle --wrap setup; and I'd pay attention for this case when improving/refactoring --wrap in LLD to not cause you additional trouble)

Also state that the --wrap behavior is specific to LLD.

Agreed and thanks for considering us :)

Do you want me to close this review and put up another one with the improvements to the description that you have recommended (maybe not even mentioning the --wrap behaviour at all), or should I update this review?

[MaskRay]

Updating the summary should be fine.

The two new tests code-model-elf-pic-sip.ll and code-model-elf-pic-nosip.ll are a bit too long. It seems to me we just need an additional variable in test/CodeGen/X86/linux-preemption.ll and we will be good. There may be value improving test coverage but the excessive testing in code-model-elf-pic-sip.ll and code-model-elf-pic-nosip.ll should probably go to a separate change. (I do wonder whether they duplicate existing testing)

[bd1976llvm]

Moved testing into linux-preemption.ll

[bd1976llvm]

In D85782#2211672, @bd1976llvm wrote:

In D85782#2211636, @MaskRay wrote:

GNU now recommends -fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility) so my understanding is that there will be very few STV_DEFAULT symbols.

I am not very sure this is now recommended but is indeed a non-rare configuration we should care about.

Agreed. Recommended is probably too strong.

I was sure that I had read this somewhere. From the following GCC page: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fvisibility

-fvisibility=[default|internal|hidden|protected]
...It is strongly recommended that you use this in any shared objects you distribute.

[MaskRay]

Thanks!

[skan]

I think this introduces an old issue when lowering the instruction.

Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=13600

Reproducer:

__attribute__((visibility("protected"))) void * foo (void) { return (void *)foo; }

clang -c  -O0  -fpic test.c 
clang -O0  -fpic test.o  -shared

Error message:
bfd/bin/ld: test.o: relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object

Analysis:
Consider visibility in canBenefitFromLocalAlias function limits the MC's ability to use local reference when selecting operand.

Before this patch, the assemble looks like

        .text
        .file   "test.c"
        .protected      foo                     # -- Begin function foo
        .globl  foo
        .p2align        4, 0x90
        .type   foo,@function
foo:                                    # @foo
.Lfoo$local:
        .cfi_startproc
# %bb.0:                                # %entry
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset %rbp, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register %rbp
        leaq    .Lfoo$local(%rip), %rax
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq
.Lfunc_end0:

.Lfoo$local(%rip) can be calculated directly and is not a relocation when emiting object file, so we no need to worry about the visibility of foo.

After this patch

leaq    .Lfoo$local(%rip), %rax    ->  leaq    foo(%rip), %rax

The visibility of foo conflicts with the relocation type..

[bd1976llvm]

In D85782#2235567, @skan wrote:

I think this introduces an old issue when lowering the instruction.

Thanks for reporting this. I will need to refresh my understanding on this. Use of protected visibility is rare. The gcc bug is unclear... reading though it they haven't come up with a decision as to what behaviour they want yet. As things stand we now seem to match the current gcc behaviour. We could go back to the original behaviour or we could emit a R_X86_64_PLT32 rather than R_X86_64_PC32 (which is probably the more "correct" ELF thing to do). @MaskRay?

[MaskRay]

In D85782#2235567, @skan wrote:

I think this introduces an old issue when lowering the instruction.

Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=13600

Reproducer:

__attribute__((visibility("protected"))) void * foo (void) { return (void *)foo; }

clang -c  -O0  -fpic test.c 
clang -O0  -fpic test.o  -shared

Error message:
bfd/bin/ld: test.o: relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object

Analysis:
Consider visibility in canBenefitFromLocalAlias function limits the MC's ability to use local reference when selecting operand.

Before this patch, the assemble looks like

        .text
        .file   "test.c"
        .protected      foo                     # -- Begin function foo
        .globl  foo
        .p2align        4, 0x90
        .type   foo,@function
foo:                                    # @foo
.Lfoo$local:
        .cfi_startproc
# %bb.0:                                # %entry
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset %rbp, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register %rbp
        leaq    .Lfoo$local(%rip), %rax
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq
.Lfunc_end0:

.Lfoo$local(%rip) can be calculated directly and is not a relocation when emiting object file, so we no need to worry about the visibility of foo.

After this patch

leaq    .Lfoo$local(%rip), %rax    ->  leaq    foo(%rip), %rax

The visibility of foo conflicts with the relocation type..

tl;dr This is a longstanding GNU ld bug introduced in binutils 2.26

% cat a.c
__attribute__((visibility("protected"))) void * foo (void) { return (void *)foo; }
% gcc -fpic a.c -shared -fuse-ld=bfd # relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object

clang does not behave worse than GCC+GNU ld, so there is no regression on our side.

---

Longer answer:

binutils 2.26 introduced a regression: R_X86_64_PC32 can no longer be used against a protected symbol https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5

The original issue is "Copy relocation against protected symbol doesn't work".
I agree with Rich Felker (https://gcc.gnu.org/ml/gcc/2016-04/msg00168.html) and
Cary Coutant (https://sourceware.org/ml/binutils/2016-03/msg00407.html https://gcc.gnu.org/ml/gcc/2016-04/msg00158.html https://gcc.gnu.org/ml/gcc/2016-04/msg00169.html) that we should
keep using direct access against protected symbols and disallow copy relocations against protected symbols.

I appreciate that Cary Coutant and Rafael Ávila de Espíndola added diagnostics to gold and lld, respectively:

• gold (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
• lld (https://bugs.llvm.org/show_bug.cgi?id=31476)

@skan Perhaps you are in a good position to change the resolutions to the following issues:)

GCC 5 x86-64 introduced a regression (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248) I suggested a fix in May, 2019: https://sourceware.org/pipermail/gcc/2019-May/229309.html
i386 was flagged as a reproduce (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012)

__attribute__((visibility("protected"))) int a;
int foo() { return a; } // GCC>=5 uses R_X86_64_GOTPCREL/R_X86_64_REX_GOTPCRELX instead of R_X86_64_PC32

binutils 2.26 introduced a regression R_X86_64_PC32 can no longer be used against a protected symbol https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5

[bd1976llvm]

In D85782#2236493, @MaskRay wrote:

tl;dr This is a longstanding GNU ld bug introduced in binutils 2.26

% cat a.c
__attribute__((visibility("protected"))) void * foo (void) { return (void *)foo; }
% gcc -fpic a.c -shared -fuse-ld=bfd # relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object

clang does not behave worse than GCC+GNU ld, so there is no regression on our side.

Sorry I was in a rush and made a mistake in my reply when I mentioned PLT relocations. That was just a mistake.. I meant to say that we could access via the GOT.

Thanks @MaskRay - awesome reply.

[skan]

In D85782#2236493, @MaskRay wrote:

Longer answer:

binutils 2.26 introduced a regression: R_X86_64_PC32 can no longer be used against a protected symbol https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5

The original issue is "Copy relocation against protected symbol doesn't work".
I agree with Rich Felker (https://gcc.gnu.org/ml/gcc/2016-04/msg00168.html) and
Cary Coutant (https://sourceware.org/ml/binutils/2016-03/msg00407.html https://gcc.gnu.org/ml/gcc/2016-04/msg00158.html https://gcc.gnu.org/ml/gcc/2016-04/msg00169.html) that we should
keep using direct access against protected symbols and disallow copy relocations against protected symbols.

I appreciate that Cary Coutant and Rafael Ávila de Espíndola added diagnostics to gold and lld, respectively:

• gold (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
• lld (https://bugs.llvm.org/show_bug.cgi?id=31476)

@skan Perhaps you are in a good position to change the resolutions to the following issues:)

GCC 5 x86-64 introduced a regression (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248) I suggested a fix in May, 2019: https://sourceware.org/pipermail/gcc/2019-May/229309.html
i386 was flagged as a reproduce (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012)

__attribute__((visibility("protected"))) int a;
int foo() { return a; } // GCC>=5 uses R_X86_64_GOTPCREL/R_X86_64_REX_GOTPCRELX instead of R_X86_64_PC32

binutils 2.26 introduced a regression R_X86_64_PC32 can no longer be used against a protected symbol https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5

Thanks, this information is helpful to me. @MaskRay What's resolution do you want me to change?
"thus I suggest we make HAVE_LD_PIE_COPYRELOC non-default" this one?

[bd1976llvm]

@hans, I think that we should put this change onto the release branch for llvm11.

[hans]

In D85782#2273402, @bd1976llvm wrote:

@hans, I think that we should put this change onto the release branch for llvm11.

I'm not familiar with the details of this patch, can you explain why we should merge it to llvm11?

We're very late in the release process, so unless it's fixing some major problem, I would be hesitant to merge.

[bd1976llvm]

In D85782#2273938, @hans wrote:

In D85782#2273402, @bd1976llvm wrote:

@hans, I think that we should put this change onto the release branch for llvm11.

I'm not familiar with the details of this patch, can you explain why we should merge it to llvm11?

We're very late in the release process, so unless it's fixing some major problem, I would be hesitant to merge.

Apologies - I failed to consider where LLVM is in the release process!

This isn't needed to fix a major problem. However, it would be great to get this patch into a released LLVM ASAP to prevent users coming to rely on the behaviour prior to this patch. See report by @skan above. The patch should be very safe as it essentially restores the referencing behaviour to what it was prior to https://reviews.llvm.org/D73230 for symbol definitions that do not have default ELF visibility.

If you have to do another RC it would be worth considering merging this.

[MaskRay]

In D85782#2276676, @bd1976llvm wrote:

In D85782#2273938, @hans wrote:

In D85782#2273402, @bd1976llvm wrote:

@hans, I think that we should put this change onto the release branch for llvm11.

I'm not familiar with the details of this patch, can you explain why we should merge it to llvm11?

We're very late in the release process, so unless it's fixing some major problem, I would be hesitant to merge.

Apologies - I failed to consider where LLVM is in the release process!

This isn't needed to fix a major problem. However, it would be great to get this patch into a released LLVM ASAP to prevent users coming to rely on the behaviour prior to this patch. See report by @skan above. The patch should be very safe as it essentially restores the referencing behaviour to what it was prior to https://reviews.llvm.org/D73230 for symbol definitions that do not have default ELF visibility.

I testify that this patch is safe. With this patch the behavior is closer to GCC.

(skan's report is a GNU ld x86 bug and has been always the case in GCC x86 + GNU ld circa 2015)

If you have to do another RC it would be worth considering merging this.

[hans]

Okay, cherry-picked to 11.x as 80e2fc1e6e68d6ed57dccc03c6a5121e216bfd43.

llvm/lib/IR/Globals.cpp

bool GlobalValue::isInterposable() const {
   if (isInterposableLinkage(getLinkage()))
     return true;
   return getParent() && getParent()->getSemanticInterposition() &&
          !isDSOLocal();
 }
 
 bool GlobalValue::canBenefitFromLocalAlias() const {
   // See AsmPrinter::getSymbolPreferLocal().
-  return GlobalObject::isExternalLinkage(getLinkage()) && !isDeclaration() &&
+  return hasDefaultVisibility() &&
+         GlobalObject::isExternalLinkage(getLinkage()) && !isDeclaration() &&
          !isa<GlobalIFunc>(this) && !hasComdat();
 }
 
 unsigned GlobalValue::getAddressSpace() const {
   PointerType *PtrTy = getType();
   return PtrTy->getAddressSpace();
 }
 

llvm/test/CodeGen/AArch64/emutls.ll

 ; ARM64:      .section .rodata,
 ; ARM64-LABEL: __emutls_t.i3:
 ; ARM64-NEXT: .word 15
 
 ; ARM64:      .hidden __emutls_v.i4
 ; ARM64:      .data{{$}}
 ; ARM64:      .globl __emutls_v.i4
 ; ARM64-LABEL: __emutls_v.i4:
-; ARM64-NEXT: .L__emutls_v.i4$local:
 ; ARM64-NEXT: .xword 4
 ; ARM64-NEXT: .xword 4
 ; ARM64-NEXT: .xword 0
 ; ARM64-NEXT: .xword __emutls_t.i4
 
 ; ARM64:      .section .rodata,
 ; ARM64-LABEL: __emutls_t.i4:
-; ARM64-NEXT: .L__emutls_t.i4$local:
 ; ARM64-NEXT: .word 15
 
 ; ARM64-NOT:   __emutls_v.i5:
 ; ARM64:      .hidden __emutls_v.i5
 ; ARM64-NOT:   __emutls_v.i5:
 
 ; ARM64:      .data{{$}}
 ; ARM64:      .globl __emutls_v.s1

llvm/test/CodeGen/ARM/emutls.ll

 
 ; ARM32:      .section .rodata,
 ; ARM32-LABEL: __emutls_t.i3:
 ; ARM32-NEXT: .long 15
 
 ; ARM32:      .data{{$}}
 ; ARM32:      .globl __emutls_v.i4
 ; ARM32-LABEL: __emutls_v.i4:
-; ARM32-NEXT:  .L__emutls_v.i4$local:
 ; ARM32-NEXT: .long 4
 ; ARM32-NEXT: .long 4
 ; ARM32-NEXT: .long 0
 ; ARM32-NEXT: .long __emutls_t.i4
 
 ; ARM32:      .section .rodata,
 ; ARM32-LABEL: __emutls_t.i4:
-; ARM32-NEXT:  .L__emutls_t.i4$local:
 ; ARM32-NEXT: .long 15
 
 ; ARM32-NOT:   __emutls_v.i5:
 ; ARM32:      .hidden __emutls_v.i5
 ; ARM32-NOT:   __emutls_v.i5:
 
 ; ARM32:      .data{{$}}
 ; ARM32:      .globl __emutls_v.s1

llvm/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll

 ; RUN: llc < %s -relocation-model=pic | FileCheck %s
 ; PR2137
 
 ; ModuleID = '1.c'
 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
 target triple = "i386-pc-linux-gnu"
   %struct.__res_state = type { i32 }
 @__resp = thread_local global %struct.__res_state* @_res    ; <%struct.__res_state**> [#uses=1]
 @_res = global %struct.__res_state zeroinitializer, section ".bss"    ; <%struct.__res_state*> [#uses=1]
 
 @__libc_resp = hidden thread_local alias %struct.__res_state*, %struct.__res_state** @__resp    ; <%struct.__res_state**> [#uses=2]
 
 define i32 @foo() {
 ; CHECK-LABEL: foo:
-; CHECK: leal    .L__libc_resp$local@TLSLDM
+; CHECK: leal    __libc_resp@TLSLD
 entry:
   %retval = alloca i32    ; <i32*> [#uses=1]
   %"alloca point" = bitcast i32 0 to i32    ; <i32> [#uses=0]
   %tmp = load %struct.__res_state*, %struct.__res_state** @__libc_resp, align 4    ; <%struct.__res_state*> [#uses=1]
   %tmp1 = getelementptr %struct.__res_state, %struct.__res_state* %tmp, i32 0, i32 0    ; <i32*> [#uses=1]
   store i32 0, i32* %tmp1, align 4
   br label %return
 return:   ; preds = %entry
   %retval2 = load i32, i32* %retval    ; <i32> [#uses=1]
   ret i32 %retval2
 }
 
 define i32 @bar() {
 ; CHECK-LABEL: bar:
-; CHECK: leal    .L__libc_resp$local@TLSLDM
+; CHECK: leal    __libc_resp@TLSLD
 entry:
   %retval = alloca i32    ; <i32*> [#uses=1]
   %"alloca point" = bitcast i32 0 to i32    ; <i32> [#uses=0]
   %tmp = load %struct.__res_state*, %struct.__res_state** @__libc_resp, align 4    ; <%struct.__res_state*> [#uses=1]
   %tmp1 = getelementptr %struct.__res_state, %struct.__res_state* %tmp, i32 0, i32 0    ; <i32*> [#uses=1]
   store i32 1, i32* %tmp1, align 4
   br label %return
 return:   ; preds = %entry
   %retval2 = load i32, i32* %retval    ; <i32> [#uses=1]
   ret i32 %retval2
 }

llvm/test/CodeGen/X86/linux-preemption.ll

 @strong_default_global = global i32 42
 define i32* @get_strong_default_global() {
   ret i32* @strong_default_global
 }
 ; CHECK: movq strong_default_global@GOTPCREL(%rip), %rax
 ; STATIC: movl $strong_default_global, %eax
 ; CHECK32: movl strong_default_global@GOT(%eax), %eax
 
+@strong_hidden_global = hidden global i32 42
+define i32* @get_hidden_default_global() {
+  ret i32* @strong_hidden_global
+}
+; CHECK: leaq strong_hidden_global(%rip), %rax
+; STATIC: movl $strong_hidden_global, %eax
+; CHECK32: leal strong_hidden_global@GOTOFF(%eax), %eax
+
 @weak_default_global = weak global i32 42
 define i32* @get_weak_default_global() {
   ret i32* @weak_default_global
 }
 ; CHECK: movq weak_default_global@GOTPCREL(%rip), %rax
 ; STATIC: movl $weak_default_global, %eax
 ; CHECK32: movl weak_default_global@GOT(%eax), %eax
 

 @strong_default_alias = alias i32, i32* @aliasee
 define i32* @get_strong_default_alias() {
   ret i32* @strong_default_alias
 }
 ; CHECK: movq strong_default_alias@GOTPCREL(%rip), %rax
 ; STATIC: movl $strong_default_alias, %eax
 ; CHECK32: movl strong_default_alias@GOT(%eax), %eax
 
+@strong_hidden_alias = hidden alias i32, i32* @aliasee
+define i32* @get_strong_hidden_alias() {
+  ret i32* @strong_hidden_alias
+}
+; CHECK: leaq strong_hidden_alias(%rip), %rax
+; STATIC: movl $strong_hidden_alias, %eax
+; CHECK32: leal strong_hidden_alias@GOTOFF(%eax), %eax
+
 @weak_default_alias = weak alias i32, i32* @aliasee
 define i32* @get_weak_default_alias() {
   ret i32* @weak_default_alias
 }
 ; CHECK: movq weak_default_alias@GOTPCREL(%rip), %rax
 ; STATIC: movl $weak_default_alias, %eax
 ; CHECK32: movl weak_default_alias@GOT(%eax), %eax
 

 }
 define void()* @get_strong_default_function() {
   ret void()* @strong_default_function
 }
 ; CHECK: movq strong_default_function@GOTPCREL(%rip), %rax
 ; STATIC: movl $strong_default_function, %eax
 ; CHECK32: movl strong_default_function@GOT(%eax), %eax
 
+define hidden void @strong_hidden_function() {
+  ret void
+}
+define void()* @get_strong_hidden_function() {
+  ret void()* @strong_hidden_function
+}
+; CHECK: leaq strong_hidden_function(%rip), %rax
+; STATIC: movl $strong_hidden_function, %eax
+; CHECK32: leal strong_hidden_function@GOTOFF(%eax), %eax
+
 define weak void @weak_default_function() {
   ret void
 }
 define void()* @get_weak_default_function() {
   ret void()* @weak_default_function
 }
 ; CHECK: movq weak_default_function@GOTPCREL(%rip), %rax
 ; STATIC: movl $weak_default_function, %eax

 !llvm.module.flags = !{!0}
 !0 = !{i32 7, !"PIC Level", i32 2}
 
 ; COMMON:     {{^}}strong_local_global:
 ; CHECK-NEXT: .Lstrong_local_global$local:
 
 ; COMMON:      .globl strong_default_alias
 ; COMMON-NEXT: .set strong_default_alias, aliasee
+; COMMON-NEXT: .globl strong_hidden_alias
+; COMMON-NEXT: .hidden strong_hidden_alias
+; COMMON-NEXT: .set strong_hidden_alias, aliasee
 ; COMMON-NEXT: .weak weak_default_alias
 ; COMMON-NEXT: .set weak_default_alias, aliasee
 ; COMMON-NEXT: .globl strong_local_alias
 ; COMMON-NEXT: .set strong_local_alias, aliasee
 ; CHECK-NEXT:  .set .Lstrong_local_alias$local, aliasee
 ; COMMON-NEXT: .weak weak_local_alias
 ; COMMON-NEXT: .set weak_local_alias, aliasee
 ; COMMON-NEXT: .globl strong_preemptable_alias
 ; COMMON-NEXT: .set strong_preemptable_alias, aliasee
 ; COMMON-NEXT: .weak weak_preemptable_alias
 ; COMMON-NEXT: .set weak_preemptable_alias, aliasee

llvm/test/CodeGen/X86/semantic-interposition-comdat.ll

 ; RUN: llc -mtriple=x86_64 -relocation-model=pic < %s | FileCheck %s
 
 $comdat_func = comdat any
 
 ; CHECK-LABEL: func2:
-; CHECK-NEXT: .Lfunc2$local
+; CHECK-NOT: .Lfunc2$local
 
 declare void @func()
 
 define hidden void @func2() {
 entry:
   call void @func()
   ret void
 }

llvm/test/CodeGen/X86/tailcallpic1.ll

 ; RUN: llc < %s  -tailcallopt -mtriple=i686-pc-linux-gnu -relocation-model=pic | FileCheck %s
 
 ; This test uses guaranteed TCO so these will be tail calls, despite the early
 ; binding issues.
 
 define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) {
 entry:
   ret i32 %a3
 }
 
 define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
 entry:
   %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32 %in1, i32 %in2 )    ; <i32> [#uses=1]
   ret i32 %tmp11
-; CHECK: jmp .Ltailcallee$local
+; CHECK: jmp tailcallee
 }

llvm/test/CodeGen/X86/tailcallpic3.ll

 }
 
 define void @tailcall_hidden() {
 entry:
   tail call void @tailcallee_hidden()
   ret void
 }
 ; CHECK: tailcall_hidden:
-; CHECK: jmp .Ltailcallee_hidden$local
+; CHECK: jmp tailcallee_hidden
 
 define internal void @tailcallee_internal() {
 entry:
   ret void
 }
 
 define void @tailcall_internal() {
 entry:

llvm/test/CodeGen/X86/tailccpic1.ll

 ; RUN: llc < %s  -mtriple=i686-pc-linux-gnu -relocation-model=pic | FileCheck %s
 
 ; This test uses guaranteed TCO so these will be tail calls, despite the early
 ; binding issues.
 
 define protected tailcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) {
 entry:
   ret i32 %a3
 }
 
 define tailcc i32 @tailcaller(i32 %in1, i32 %in2) {
 entry:
   %tmp11 = tail call tailcc i32 @tailcallee( i32 %in1, i32 %in2, i32 %in1, i32 %in2 )    ; <i32> [#uses=1]
   ret i32 %tmp11
-; CHECK: jmp .Ltailcallee$local
+; CHECK: jmp tailcallee
 }