llvm-project/lld/ELF/ICF.h

//===- ICF.h --------------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//

#ifndef LLD_ELF_ICF_H
#define LLD_ELF_ICF_H

namespace lld::elf {

template <class ELFT> void doIcf();

}

#endif
ELF: Implement ICF. This patch implements the same algorithm as LLD/COFF's ICF. I'm not going to repeat the same description about how it works, so you want to read the comment in ICF.cpp in this patch if you want to know the details. This algorithm should be more powerful than the ICF algorithm implemented in GNU gold. It can even merge mutually-recursive functions (which is harder than one might think). ICF is a fairly effective size optimization. Here are some examples. LLD: 37.14 MB -> 35.80 MB (-3.6%) Clang: 59.41 MB -> 57.80 MB (-2.7%) The lacking feature is "safe" version of ICF. This merges all identical sections. That is not compatible with a C/C++ language requirement that two distinct functions must have distinct addresses. But as long as your program do not rely on the pointer equality (which is in many cases true), your program should work with the feature. LLD works fine for example. GNU gold implements so-called "safe ICF" that identifies functions that are safe to merge by heuristics -- for example, gold thinks that constructors are safe to merge because there is no way to take an address of a constructor in C++. We have a different idea which David Majnemer suggested that we add NOPs at beginning of merged functions so that two or more pointers can have distinct values. We can do whichever we want, but this patch does not include neither. http://reviews.llvm.org/D17529 llvm-svn: 261912 2016-02-26 02:43:51 +08:00			`//===- ICF.h --------------------------------------------------------------===//`
			`//`
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2019-01-19 16:50:56 +08:00			`// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.`
			`// See https://llvm.org/LICENSE.txt for license information.`
			`// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception`
ELF: Implement ICF. This patch implements the same algorithm as LLD/COFF's ICF. I'm not going to repeat the same description about how it works, so you want to read the comment in ICF.cpp in this patch if you want to know the details. This algorithm should be more powerful than the ICF algorithm implemented in GNU gold. It can even merge mutually-recursive functions (which is harder than one might think). ICF is a fairly effective size optimization. Here are some examples. LLD: 37.14 MB -> 35.80 MB (-3.6%) Clang: 59.41 MB -> 57.80 MB (-2.7%) The lacking feature is "safe" version of ICF. This merges all identical sections. That is not compatible with a C/C++ language requirement that two distinct functions must have distinct addresses. But as long as your program do not rely on the pointer equality (which is in many cases true), your program should work with the feature. LLD works fine for example. GNU gold implements so-called "safe ICF" that identifies functions that are safe to merge by heuristics -- for example, gold thinks that constructors are safe to merge because there is no way to take an address of a constructor in C++. We have a different idea which David Majnemer suggested that we add NOPs at beginning of merged functions so that two or more pointers can have distinct values. We can do whichever we want, but this patch does not include neither. http://reviews.llvm.org/D17529 llvm-svn: 261912 2016-02-26 02:43:51 +08:00			`//`
			`//===----------------------------------------------------------------------===//`

			`#ifndef LLD_ELF_ICF_H`
			`#define LLD_ELF_ICF_H`

[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 2022-08-11 03:31:58 +08:00			`namespace lld::elf {`
Consistent use of header file for ICF and MarkLive Previously wasm used a separate header to declare markLive and ELF used to declare ICF. This change makes each backend consistently declare these in their own headers. Differential Revision: https://reviews.llvm.org/D43529 llvm-svn: 325631 2018-02-21 06:09:59 +08:00
Do not pass Symtab to markLive/doICF since Symtab is globally accessible. llvm-svn: 268286 2016-05-03 03:30:42 +08:00			`template <class ELFT> void doIcf();`
Consistent use of header file for ICF and MarkLive Previously wasm used a separate header to declare markLive and ELF used to declare ICF. This change makes each backend consistently declare these in their own headers. Differential Revision: https://reviews.llvm.org/D43529 llvm-svn: 325631 2018-02-21 06:09:59 +08:00
[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 2022-08-11 03:31:58 +08:00			`}`
ELF: Implement ICF. This patch implements the same algorithm as LLD/COFF's ICF. I'm not going to repeat the same description about how it works, so you want to read the comment in ICF.cpp in this patch if you want to know the details. This algorithm should be more powerful than the ICF algorithm implemented in GNU gold. It can even merge mutually-recursive functions (which is harder than one might think). ICF is a fairly effective size optimization. Here are some examples. LLD: 37.14 MB -> 35.80 MB (-3.6%) Clang: 59.41 MB -> 57.80 MB (-2.7%) The lacking feature is "safe" version of ICF. This merges all identical sections. That is not compatible with a C/C++ language requirement that two distinct functions must have distinct addresses. But as long as your program do not rely on the pointer equality (which is in many cases true), your program should work with the feature. LLD works fine for example. GNU gold implements so-called "safe ICF" that identifies functions that are safe to merge by heuristics -- for example, gold thinks that constructors are safe to merge because there is no way to take an address of a constructor in C++. We have a different idea which David Majnemer suggested that we add NOPs at beginning of merged functions so that two or more pointers can have distinct values. We can do whichever we want, but this patch does not include neither. http://reviews.llvm.org/D17529 llvm-svn: 261912 2016-02-26 02:43:51 +08:00
			`#endif`