maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/MachO/lto-internalize.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

107 lines
3.4 KiB
LLVM
Raw Normal View History

[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
; REQUIRES: x86
;; Check that we internalize bitcode symbols (only) where possible, i.e. when
;; they are not referenced by undefined symbols originating from non-bitcode
;; files.
; RUN: rm -rf %t; split-file %s %t
; RUN: llvm-as %t/test.s -o %t/test.o
; RUN: llvm-as %t/baz.s -o %t/baz.o
; RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/regular.s -o %t/regular.o
[lld-macho][nfc] Remove unnecessary -pie flags in tests D101513 means that we no longer need to specify `-pie` in most of our test RUN commands. Let's clean up the unused flags so as not to confuse future test writers. Reviewed By: #lld-macho, oontvoo, MaskRay Differential Revision: https://reviews.llvm.org/D113114
2021-11-04 12:01:49 +08:00
; RUN: %lld -lSystem %t/test.o %t/baz.o %t/regular.o -o %t/test -save-temps
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
; RUN: llvm-dis < %t/test.0.2.internalize.bc | FileCheck %s
; RUN: llvm-objdump --macho --syms %t/test | FileCheck %s --check-prefix=SYMTAB
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
; CHECK: @comm = internal global
; CHECK: @comm_hide = internal global
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
;; Check that main is not internalized. This covers the case of bitcode symbols
;; referenced by undefined symbols that don't belong to any InputFile.
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the `interposable` used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506
2022-03-16 08:25:06 +08:00
; CHECK: define dso_local void @main()
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
;; Check that the foo and bar functions are correctly internalized.
; CHECK: define internal void @bar()
; CHECK: define internal void @foo()
;; Check that a bitcode symbol that is referenced by a regular object file isn't
;; internalized.
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the `interposable` used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506
2022-03-16 08:25:06 +08:00
; CHECK: define dso_local void @used_in_regular_obj()
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
;; Check that a bitcode symbol that is defined in another bitcode file gets
;; internalized.
; CHECK: define internal void @baz()
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
;; Check that all internalized symbols are not emitted to the symtab
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
; SYMTAB-LABEL: SYMBOL TABLE:
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
; SYMTAB-DAG: g F __TEXT,__text _main
; SYMTAB-DAG: g F __TEXT,__text _used_in_regular_obj
; SYMTAB-DAG: g F __TEXT,__text __mh_execute_header
; SYMTAB-DAG: *UND* dyld_stub_binder
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
; SYMTAB-EMPTY:
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
; RUN: %lld -lSystem -dylib %t/test.o %t/baz.o %t/regular.o -o %t/test.dylib -save-temps
; RUN: llvm-dis < %t/test.dylib.0.2.internalize.bc | FileCheck %s --check-prefix=DYN
; RUN: llvm-nm -m %t/test.dylib | FileCheck %s --check-prefix=DYN-SYMS \
; RUN: --implicit-check-not _foo
; RUN: %lld -lSystem -export_dynamic %t/test.o %t/baz.o %t/regular.o -o %t/test.extdyn -save-temps
; RUN: llvm-dis < %t/test.extdyn.0.2.internalize.bc
; RUN: llvm-nm -m %t/test.extdyn | FileCheck %s --check-prefix=DYN-SYMS \
; RUN: --implicit-check-not _foo
;; Note that only foo() gets internalized here; everything else that isn't
;; hidden must be exported.
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the `interposable` used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506
2022-03-16 08:25:06 +08:00
; DYN: @comm = common dso_local global
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
; DYN: @comm_hide = internal global
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the `interposable` used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506
2022-03-16 08:25:06 +08:00
; DYN: define dso_local void @main()
; DYN: define dso_local void @bar()
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
; DYN: define internal void @foo()
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the `interposable` used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506
2022-03-16 08:25:06 +08:00
; DYN: define dso_local void @used_in_regular_obj()
; DYN: define dso_local void @baz()
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
; DYN-SYMS-DAG: (__TEXT,__text) external _bar
; DYN-SYMS-DAG: (__TEXT,__text) external _baz
; DYN-SYMS-DAG: (__DATA,__common) external _comm
; DYN-SYMS-DAG: (__TEXT,__text) external _main
; DYN-SYMS-DAG: (__TEXT,__text) external _used_in_regular_obj
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
;--- test.s
[lld-macho] Have tests default to targeting macos 10.15 D101114 enforced proper version checks, which exposed a variety of version mismatch issues in our tests. We previously changed the test inputs to target 10.0, which was the simpler thing to do, but we should really just have our lit.local.cfg default to targeting 10.15, which is what is done here. We're not likely to ever have proper support for the older versions anyway, as that would require more work for unclear benefit; for instance, llvm-mc seems to generate a different compact unwind format for older macOS versions, which would cause our compact-unwind.s test to fail. Targeting 10.15 by default causes the following behavioral changes: * `__mh_execute_header` is now a section symbol instead of an absolute symbol * LC_BUILD_VERSION gets emitted instead of LC_VERSION_MIN_MACOSX. The former is 32 bytes in size whereas the latter is 16 bytes, so a bunch of hardcoded address offsets in our tests had to be updated. * >= 10.6 executables are PIE by default Note that this diff was stacked atop of a local revert of most of the test changes in rG8c17a875150f8e736e8f9061ddf084397f45f4c5, to make review easier. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D101119
2021-04-23 07:37:47 +08:00
target triple = "x86_64-apple-macosx10.15.0"
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
[lld-macho] Unset ExportDynamic where possible for LTO By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes https://github.com/llvm/llvm-project/issues/50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
2022-02-12 11:24:09 +08:00
;; Common symbols are always external.
@comm = common global i8 0, align 1
@comm_hide = common hidden global i8 0, align 1
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
declare void @baz()
define void @main() {
call void @bar()
call void @baz()
ret void
}
define void @bar() {
ret void
}
define hidden void @foo() {
ret void
}
define void @used_in_regular_obj() {
ret void
}
;--- baz.s
[lld-macho] Have tests default to targeting macos 10.15 D101114 enforced proper version checks, which exposed a variety of version mismatch issues in our tests. We previously changed the test inputs to target 10.0, which was the simpler thing to do, but we should really just have our lit.local.cfg default to targeting 10.15, which is what is done here. We're not likely to ever have proper support for the older versions anyway, as that would require more work for unclear benefit; for instance, llvm-mc seems to generate a different compact unwind format for older macOS versions, which would cause our compact-unwind.s test to fail. Targeting 10.15 by default causes the following behavioral changes: * `__mh_execute_header` is now a section symbol instead of an absolute symbol * LC_BUILD_VERSION gets emitted instead of LC_VERSION_MIN_MACOSX. The former is 32 bytes in size whereas the latter is 16 bytes, so a bunch of hardcoded address offsets in our tests had to be updated. * >= 10.6 executables are PIE by default Note that this diff was stacked atop of a local revert of most of the test changes in rG8c17a875150f8e736e8f9061ddf084397f45f4c5, to make review easier. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D101119
2021-04-23 07:37:47 +08:00
target triple = "x86_64-apple-macosx10.15.0"
[lld-macho] LTO: Unset VisibleToRegularObj where possible This allows LLVM's LTO to internalize symbols that are not referenced directly by regular objects. Naturally, this means we need to track which symbols are referenced by regular objects. The approach taken here is similar to LLD-COFF's: like the COFF port, we extend `SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF relies on the Symbol constructor and `Symbol::mergeProperties()`, but the Mach-O port does not have a `mergeProperties()` equivalent.) From what I can tell, ld64 (which uses libLTO) doesn't do this optimization at all. I'm not even sure libLTO provides a way to do this. Not having ld64's behavior as a reference implementation is unfortunate; instead, I am relying on LLD-ELF/COFF's behavior as references while erring on the conservative side. In particular, LLD-MachO will only do this optimization for executables right now. We also don't attempt it when `-flat_namespace` is used -- otherwise we'd need scan the symbol table to find matches for every un-namespaced symbol reference, which is expensive. internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and `internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize tests, so adding him as a reviewer... Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99105
2021-04-16 09:14:29 +08:00
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
define void @baz() {
ret void
}
;--- regular.s
.data
.quad _used_in_regular_obj