| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[ELF][AArch64] Relax zero TLSLE add to nop (#204286) Optimize AArch64 local-exec TLS relocation handling by replacing a self-add R_AARCH64_TLSLE_ADD_TPREL_HI12 instruction with nop when the high 12 bits are zero. The optimization is disabled by --no-relax and avoids non-equivalent forms such as non-self-adds and 32-bit destination registers. | 1 个月前 | |
[llvm] Add missing StringExtras.h includes In preparation for removing the #include "llvm/ADT/StringExtras.h" from the header to source file of llvm/Support/Error.h, first add in all the missing includes that were previously included transitively through this header. | 3 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[lld] StringRef::{starts,ends}with => {starts,ends}_with. NFC The latter form is now preferred to be similar to C++20 starts_with. This replacement also removes one function call when startswith is not inlined. | 3 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[Backport][ELF] A new code layout algorithm for function reordering [3a/3] We are brining a new algorithm for function layout (reordering) based on the call graph (extracted from a profile data). The algorithm is an improvement of top of a known heuristic, C^3. It tries to co-locate hot and frequently executed together functions in the resulting ordering. Unlike C^3, it explores a larger search space and have an objective closely tied to the performance of instruction and i-TLB caches. Hence, the name CDS = Cache-Directed Sort. The algorithm can be used at the linking or post-linking (e.g., BOLT) stage. Refer to https://reviews.llvm.org/D152834 for the actual implementation of the reordering algorithm. This diff adds a linker option to replace the existing C^3 heuristic with CDS. The new behavior can be turned on by passing "--use-cache-directed-sort". (the plan is to make it default in a next diff) **Perf-impact** clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in [0.3%..0.8%] rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in [0.8%..1.5%] Note that function layout affects the perf the most on older machines (with smaller instruction/iTLB caches) and when huge pages are not enabled. The impact on newer processors with huge pages enabled is likely neutral/minor. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D152840 | 11 个月前 | |
[Backport][ELF] A new code layout algorithm for function reordering [3a/3] We are brining a new algorithm for function layout (reordering) based on the call graph (extracted from a profile data). The algorithm is an improvement of top of a known heuristic, C^3. It tries to co-locate hot and frequently executed together functions in the resulting ordering. Unlike C^3, it explores a larger search space and have an objective closely tied to the performance of instruction and i-TLB caches. Hence, the name CDS = Cache-Directed Sort. The algorithm can be used at the linking or post-linking (e.g., BOLT) stage. Refer to https://reviews.llvm.org/D152834 for the actual implementation of the reordering algorithm. This diff adds a linker option to replace the existing C^3 heuristic with CDS. The new behavior can be turned on by passing "--use-cache-directed-sort". (the plan is to make it default in a next diff) **Perf-impact** clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in [0.3%..0.8%] rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in [0.8%..1.5%] Note that function layout affects the perf the most on older machines (with smaller instruction/iTLB caches) and when huge pages are not enabled. The impact on newer processors with huge pages enabled is likely neutral/minor. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D152840 | 11 个月前 | |
[Backport][ELF] A new code layout algorithm for function reordering [3a/3] We are brining a new algorithm for function layout (reordering) based on the call graph (extracted from a profile data). The algorithm is an improvement of top of a known heuristic, C^3. It tries to co-locate hot and frequently executed together functions in the resulting ordering. Unlike C^3, it explores a larger search space and have an objective closely tied to the performance of instruction and i-TLB caches. Hence, the name CDS = Cache-Directed Sort. The algorithm can be used at the linking or post-linking (e.g., BOLT) stage. Refer to https://reviews.llvm.org/D152834 for the actual implementation of the reordering algorithm. This diff adds a linker option to replace the existing C^3 heuristic with CDS. The new behavior can be turned on by passing "--use-cache-directed-sort". (the plan is to make it default in a next diff) **Perf-impact** clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in [0.3%..0.8%] rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in [0.8%..1.5%] Note that function layout affects the perf the most on older machines (with smaller instruction/iTLB caches) and when huge pages are not enabled. The impact on newer processors with huge pages enabled is likely neutral/minor. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D152840 | 11 个月前 | |
[Backport][ELF] A new code layout algorithm for function reordering [3a/3] We are brining a new algorithm for function layout (reordering) based on the call graph (extracted from a profile data). The algorithm is an improvement of top of a known heuristic, C^3. It tries to co-locate hot and frequently executed together functions in the resulting ordering. Unlike C^3, it explores a larger search space and have an objective closely tied to the performance of instruction and i-TLB caches. Hence, the name CDS = Cache-Directed Sort. The algorithm can be used at the linking or post-linking (e.g., BOLT) stage. Refer to https://reviews.llvm.org/D152834 for the actual implementation of the reordering algorithm. This diff adds a linker option to replace the existing C^3 heuristic with CDS. The new behavior can be turned on by passing "--use-cache-directed-sort". (the plan is to make it default in a next diff) **Perf-impact** clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in [0.3%..0.8%] rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in [0.8%..1.5%] Note that function layout affects the perf the most on older machines (with smaller instruction/iTLB caches) and when huge pages are not enabled. The impact on newer processors with huge pages enabled is likely neutral/minor. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D152840 | 11 个月前 | |
[DebugInfo] llvm::Optional => std::optional https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lld] Change Optional to std::optional https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[Backport][ELF] A new code layout algorithm for function reordering [3a/3] We are brining a new algorithm for function layout (reordering) based on the call graph (extracted from a profile data). The algorithm is an improvement of top of a known heuristic, C^3. It tries to co-locate hot and frequently executed together functions in the resulting ordering. Unlike C^3, it explores a larger search space and have an objective closely tied to the performance of instruction and i-TLB caches. Hence, the name CDS = Cache-Directed Sort. The algorithm can be used at the linking or post-linking (e.g., BOLT) stage. Refer to https://reviews.llvm.org/D152834 for the actual implementation of the reordering algorithm. This diff adds a linker option to replace the existing C^3 heuristic with CDS. The new behavior can be turned on by passing "--use-cache-directed-sort". (the plan is to make it default in a next diff) **Perf-impact** clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in [0.3%..0.8%] rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in [0.8%..1.5%] Note that function layout affects the perf the most on older machines (with smaller instruction/iTLB caches) and when huge pages are not enabled. The impact on newer processors with huge pages enabled is likely neutral/minor. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D152840 | 11 个月前 | |
[OptTable] Precompute OptTable prefixes union table through tablegen This avoid rediscovering this table when reading each options, providing a sensible 2% speedup when processing and empty file, and a measurable speedup on typical workloads, see: This is optional, the legacy, on-the-fly, approach can still be used through the GenericOptTable class, while the new one is used through PrecomputedOptTable. https://llvm-compile-time-tracker.com/compare.php?from=4da6cb3202817ee2897d6b690e4af950459caea4&to=19a492b704e8f5c1dea120b9c0d3859bd78796be&stat=instructions:u Differential Revision: https://reviews.llvm.org/D140800 | 3 年前 | |
[lld] StringRef::{starts,ends}with => {starts,ends}_with. NFC The latter form is now preferred to be similar to C++20 starts_with. This replacement also removes one function call when startswith is not inlined. | 3 年前 | |
[ELF] Change rawData to content() and data() to contentMaybeDecompress() Clarify data() which may trigger decompression and make it feasible to refactor the member variable rawData. | 3 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[ELF] --icf: switch to xxh3_64bits for more efficient section content hashing. Also clean up the tests a bit and properly test the formatting of --print-icf-sections. | 2 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[Sw64] Add Sw64 target support for lld | 1 年前 | |
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support This commit provides linker support for Cortex-M Security Extensions (CMSE). The specification for this feature can be found in ARM v8-M Security Extensions: Requirements on Development Tools. The linker synthesizes a security gateway veneer in a special section; .gnu.sgstubs, when it finds non-local symbols __acle_se_<entry> and <entry>, defined relative to the same text section and having the same address. The address of <entry> is retargeted to the starting address of the linker-synthesized security gateway veneer in section .gnu.sgstubs. In summary, the linker translates input: .text entry: __acle_se_entry: [entry_code] into: .section .gnu.sgstubs entry: SG B.W __acle_se_entry .text __acle_se_entry: [entry_code] If addresses of __acle_se_<entry> and <entry> are not equal, the linker considers that <entry> already defines a secure gateway veneer so does not synthesize one. If --out-implib=<out.lib> is specified, the linker writes the list of secure gateway veneers into a CMSE import library <out.lib>. The CMSE import library will have 3 sections: .symtab, .strtab, .shstrtab. For every secure gateway veneer <entry> at address <addr>, .symtab contains a SHN_ABS symbol <entry> with value <addr>. If --in-implib=<in.lib> is specified, the linker reads the existing CMSE import library <in.lib> and preserves the entry function addresses in the resulting executable and new import library. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D139092 | 2 年前 | |
[Sw64] Add Sw64 target support for lld | 1 年前 | |
[lld][ELF] Support relax R_LARCH_ALIGN (#78692) Refer to commit 6611d58f5bbc ("Relax R_RISCV_ALIGN"), we can relax R_LARCH_ALIGN by same way. Reuse SymbolAnchor, RISCVRelaxAux and initSymbolAnchors to simplify codes. As riscvFinalizeRelax is an arch-specific function, put it override on TargetInfo::finalizeRelax, so that LoongArch can override it, too. The flow of relax R_LARCH_ALIGN is almost consistent with RISCV. The difference is that LoongArch only has 4-bytes NOP and all executable insn is 4-bytes aligned. So LoongArch not need rewrite NOP sequence. Alignment maxBytesEmit parameter is supported in psABI v2.30. (cherry picked from commit 06a728f3feab876f9195738b5774e82dadc0f3a7) (cherry picked from commit 60a8ec3a35c722a9eb8298c215321b89d0faf5b5) | 2 年前 | |
[NFC] Apply clang-format. [NFC] Delete unused code segments. Do not comment them out. | 4 个月前 | |
[Backport] SplitModule in ThinLTO with callgraph | 4 个月前 | |
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support This commit provides linker support for Cortex-M Security Extensions (CMSE). The specification for this feature can be found in ARM v8-M Security Extensions: Requirements on Development Tools. The linker synthesizes a security gateway veneer in a special section; .gnu.sgstubs, when it finds non-local symbols __acle_se_<entry> and <entry>, defined relative to the same text section and having the same address. The address of <entry> is retargeted to the starting address of the linker-synthesized security gateway veneer in section .gnu.sgstubs. In summary, the linker translates input: .text entry: __acle_se_entry: [entry_code] into: .section .gnu.sgstubs entry: SG B.W __acle_se_entry .text __acle_se_entry: [entry_code] If addresses of __acle_se_<entry> and <entry> are not equal, the linker considers that <entry> already defines a secure gateway veneer so does not synthesize one. If --out-implib=<out.lib> is specified, the linker writes the list of secure gateway veneers into a CMSE import library <out.lib>. The CMSE import library will have 3 sections: .symtab, .strtab, .shstrtab. For every secure gateway veneer <entry> at address <addr>, .symtab contains a SHN_ABS symbol <entry> with value <addr>. If --in-implib=<in.lib> is specified, the linker reads the existing CMSE import library <in.lib> and preserves the entry function addresses in the resulting executable and new import library. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D139092 | 2 年前 | |
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support This commit provides linker support for Cortex-M Security Extensions (CMSE). The specification for this feature can be found in ARM v8-M Security Extensions: Requirements on Development Tools. The linker synthesizes a security gateway veneer in a special section; .gnu.sgstubs, when it finds non-local symbols __acle_se_<entry> and <entry>, defined relative to the same text section and having the same address. The address of <entry> is retargeted to the starting address of the linker-synthesized security gateway veneer in section .gnu.sgstubs. In summary, the linker translates input: .text entry: __acle_se_entry: [entry_code] into: .section .gnu.sgstubs entry: SG B.W __acle_se_entry .text __acle_se_entry: [entry_code] If addresses of __acle_se_<entry> and <entry> are not equal, the linker considers that <entry> already defines a secure gateway veneer so does not synthesize one. If --out-implib=<out.lib> is specified, the linker writes the list of secure gateway veneers into a CMSE import library <out.lib>. The CMSE import library will have 3 sections: .symtab, .strtab, .shstrtab. For every secure gateway veneer <entry> at address <addr>, .symtab contains a SHN_ABS symbol <entry> with value <addr>. If --in-implib=<in.lib> is specified, the linker reads the existing CMSE import library <in.lib> and preserves the entry function addresses in the resulting executable and new import library. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D139092 | 2 年前 | |
[ELF] Make subsequent opens to auxiliary files append Previously, the same file could be used across diagnostic options but the file would be silently overwritten by the whichever option gets handled last. Differential Revision: https://reviews.llvm.org/D153873 | 2 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support This commit provides linker support for Cortex-M Security Extensions (CMSE). The specification for this feature can be found in ARM v8-M Security Extensions: Requirements on Development Tools. The linker synthesizes a security gateway veneer in a special section; .gnu.sgstubs, when it finds non-local symbols __acle_se_<entry> and <entry>, defined relative to the same text section and having the same address. The address of <entry> is retargeted to the starting address of the linker-synthesized security gateway veneer in section .gnu.sgstubs. In summary, the linker translates input: .text entry: __acle_se_entry: [entry_code] into: .section .gnu.sgstubs entry: SG B.W __acle_se_entry .text __acle_se_entry: [entry_code] If addresses of __acle_se_<entry> and <entry> are not equal, the linker considers that <entry> already defines a secure gateway veneer so does not synthesize one. If --out-implib=<out.lib> is specified, the linker writes the list of secure gateway veneers into a CMSE import library <out.lib>. The CMSE import library will have 3 sections: .symtab, .strtab, .shstrtab. For every secure gateway veneer <entry> at address <addr>, .symtab contains a SHN_ABS symbol <entry> with value <addr>. If --in-implib=<in.lib> is specified, the linker reads the existing CMSE import library <in.lib> and preserves the entry function addresses in the resulting executable and new import library. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D139092 | 2 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[Backport][ELF] A new code layout algorithm for function reordering [3a/3] We are brining a new algorithm for function layout (reordering) based on the call graph (extracted from a profile data). The algorithm is an improvement of top of a known heuristic, C^3. It tries to co-locate hot and frequently executed together functions in the resulting ordering. Unlike C^3, it explores a larger search space and have an objective closely tied to the performance of instruction and i-TLB caches. Hence, the name CDS = Cache-Directed Sort. The algorithm can be used at the linking or post-linking (e.g., BOLT) stage. Refer to https://reviews.llvm.org/D152834 for the actual implementation of the reordering algorithm. This diff adds a linker option to replace the existing C^3 heuristic with CDS. The new behavior can be turned on by passing "--use-cache-directed-sort". (the plan is to make it default in a next diff) **Perf-impact** clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in [0.3%..0.8%] rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in [0.8%..1.5%] Note that function layout affects the perf the most on older machines (with smaller instruction/iTLB caches) and when huge pages are not enabled. The impact on newer processors with huge pages enabled is likely neutral/minor. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D152840 | 11 个月前 | |
Revert "Revert "[lld][Arm] Big Endian - Byte invariant support."" This reverts commit d8851384c6ac2a1cea15e05228dbde5f13654e23. Reason: Applied the fix for the Asan buildbot failures. | 3 年前 | |
[ELF] Change most llvm::Optional to std::optional https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
Update the documents of the new LLD. This patch merges the documents for ELF and COFF into one and puts it into docs directory. llvm-svn: 263336 | 10 年前 | |
[Sw64] Add Sw64 target support for lld | 1 年前 | |
[Sw64] Add Sw64 target support for lld | 1 年前 | |
[ELF] Support operator ^ and ^= GNU ld added ^ support in July 2023 and it looks like ^= is in plan as well. For now, we don't support a^=0 (^= without a preceding space). | 2 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
[Sw64] Add Sw64 target support for lld | 1 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 | |
reland: [Demangle] make llvm::demangle take std::string_view rather than const std::string& As suggested by @erichkeane in https://reviews.llvm.org/D141451#inline-1429549 There's potential for a lot more cleanups around these APIs. This is just a start. Callers need to be more careful about sub-expressions producing strings that don't outlast the expression using llvm::demangle. Add a release note. Differential Revision: https://reviews.llvm.org/D149104 | 3 年前 | |
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support This commit provides linker support for Cortex-M Security Extensions (CMSE). The specification for this feature can be found in ARM v8-M Security Extensions: Requirements on Development Tools. The linker synthesizes a security gateway veneer in a special section; .gnu.sgstubs, when it finds non-local symbols __acle_se_<entry> and <entry>, defined relative to the same text section and having the same address. The address of <entry> is retargeted to the starting address of the linker-synthesized security gateway veneer in section .gnu.sgstubs. In summary, the linker translates input: .text entry: __acle_se_entry: [entry_code] into: .section .gnu.sgstubs entry: SG B.W __acle_se_entry .text __acle_se_entry: [entry_code] If addresses of __acle_se_<entry> and <entry> are not equal, the linker considers that <entry> already defines a secure gateway veneer so does not synthesize one. If --out-implib=<out.lib> is specified, the linker writes the list of secure gateway veneers into a CMSE import library <out.lib>. The CMSE import library will have 3 sections: .symtab, .strtab, .shstrtab. For every secure gateway veneer <entry> at address <addr>, .symtab contains a SHN_ABS symbol <entry> with value <addr>. If --in-implib=<in.lib> is specified, the linker reads the existing CMSE import library <in.lib> and preserves the entry function addresses in the resulting executable and new import library. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D139092 | 2 年前 | |
reland: [Demangle] make llvm::demangle take std::string_view rather than const std::string& As suggested by @erichkeane in https://reviews.llvm.org/D141451#inline-1429549 There's potential for a lot more cleanups around these APIs. This is just a start. Callers need to be more careful about sub-expressions producing strings that don't outlast the expression using llvm::demangle. Add a release note. Differential Revision: https://reviews.llvm.org/D149104 | 3 年前 | |
[lld][AArch64] Add BTI landing pad to PLT when it is accessed by a range extension thunk. Adding BTI to those PLT's which accessed with by a range extension thunk due to those preform an indirect call. Fixes: #62140 Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D148704 | 3 年前 | |
[ELF] Handle relocations in synthetic .eh_frame with a non-zero offset within the output section (#65966) When the .eh_frame section is placed at a non-zero offset within its output section, the relocation value within .eh_frame are computed incorrectly. We had similar issue in .ARM.exidx section and it has been fixed already in https://reviews.llvm.org/D148033. While applying the relocation using S+A-P, the value of P (the location of the relocation) is getting wrong. P is: P = SecAddr + rel.offset, But SecAddr points to the starting address of the outputsection rather than the starting address of the eh frame section within that output section. This issue affects all targets which generates .eh_frame section. Hence fixing in all the corresponding targets it affecting. | 1 年前 | |
!186 [LLD] compiler & OS oeaware schedule opt From: @niny7 Reviewed-by: @liyunfei33 Signed-off-by: @liyunfei33 | 1 年前 | |
[ELF] Handle relocations in synthetic .eh_frame with a non-zero offset within the output section (#65966) When the .eh_frame section is placed at a non-zero offset within its output section, the relocation value within .eh_frame are computed incorrectly. We had similar issue in .ARM.exidx section and it has been fixed already in https://reviews.llvm.org/D148033. While applying the relocation using S+A-P, the value of P (the location of the relocation) is getting wrong. P is: P = SecAddr + rel.offset, But SecAddr points to the starting address of the outputsection rather than the starting address of the eh frame section within that output section. This issue affects all targets which generates .eh_frame section. Hence fixing in all the corresponding targets it affecting. | 1 年前 | |
[Sw64] Add Sw64 target support for lld | 1 年前 | |
[ARM] armv6m eXecute Only (XO) long branch Thunk This patch adds a thunk for Thumb long branch on V6-M for eXecute Only. Note that there is currently no support for a position independant and eXecute Only V6-M long branch thunk Differential Revision: https://reviews.llvm.org/D153772 | 3 年前 | |
[ELF][PPC64] Actually implement --no-power10-stubs When a caller that does not use TOC calls a function, a call stub is needed if the function may use TOC. --no-power10-stubs avoids PC-relative instructions in the code sequence. The --no-power10-stubs=no implementation added in D94627 is wrong. First, the first instruction incorrectly uses mflr 0 (instead of mflr 12). Second, for the PLT case, it uses addis+addi with getVA instead of addis+ld with getGotPltVA. | 3 年前 | |
!186 [LLD] compiler & OS oeaware schedule opt From: @niny7 Reviewed-by: @liyunfei33 Signed-off-by: @liyunfei33 | 1 年前 | |
[lld/elf] Use C++17 nested namespace syntax in most places Like D131405, but for ELF. No behavior change. Differential Revision: https://reviews.llvm.org/D131612 | 3 年前 |
See docs/NewLLD.rst