summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO/UpdateCompilerUsed.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [LTO] Account for overriding lib calls via the alias attributeWarren Ristow2018-10-101-5/+11
| | | | | | | | | | | | | Given a library call that is represented as an llvm intrinsic call, but later transformed to an actual call, if an overriding definition of that library routine is provided indirectly via an alias, prevent LTO from eliminating the definition. This is a fix for PR38547. Differential Revision: https://reviews.llvm.org/D52836 llvm-svn: 344198
* Remove redundant includes from lib/LTO.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320623
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-2/+2
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones2017-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LibFunc::Func enum holds enumerators named for libc functions. Unfortunately, there are real situations, including libc implementations, where function names are actually macros (musl uses "#define fopen64 fopen", for example; any other transitively visible macro would have similar effects). Strictly speaking, a conforming C++ Standard Library should provide any such macros as functions instead (via <cstdio>). However, there are some "library" functions which are not part of the standard, and thus not subject to this rule (fopen64, for example). So, in order to be both portable and consistent, the enum should not use the bare function names. The old enum naming used a namespace LibFunc and an enum Func, with bare enumerators. This patch changes LibFunc to be an enum with enumerators prefixed with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override macros.) There are additional changes required in clang. Reviewers: rsmith Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D28476 llvm-svn: 292848
* Utility functions for appending to llvm.used/llvm.compiler.used.Evgeniy Stepanov2016-10-251-33/+15
| | | | llvm-svn: 285143
* Move legacy LTO interface headers to legacy/ directory.Peter Collingbourne2016-07-141-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D22173 llvm-svn: 275476
* [UpdateCompilerUsed] API rename and cleanup, suggested by Rafaael.Davide Italiano2016-06-221-1/+1
| | | | | | | | | * UpdateCompilerUsed() -> updateCompilerUsed() * ThinLTO doesn't use the API so we can remove the include * Clean up unused #include <functional> from the header * Rename #ifdef guard comment to be correct. llvm-svn: 273461
* [LTO] Move UpdateCompilerUsed.h from lib/ to include/Davide Italiano2016-06-221-2/+1
| | | | | | | | I plan to use it in lld soon. Differential Revision: http://reviews.llvm.org/D21575 llvm-svn: 273380
* Simplify LTOInternalize into UpdateLLVMCompilerUsedMehdi Amini2016-04-131-0/+147
It is now only doing the update to the llvm.compiler_used global. The client has to call separately the internalization stage. Hopefully the code is simpler to understand this way. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266174
OpenPOWER on IntegriCloud