summaryrefslogtreecommitdiffstats
path: root/llvm/tools/lto/lto.cpp
Commit message (Collapse)AuthorAgeFilesLines
* LTO: Export local context symbolsDuncan P. N. Exon Smith2014-12-191-2/+13
| | | | | | | | Export symbols in libLTO.dylib for the local context-related functions added in r221733 (`LTO_API_VERSION=11`)... and add the missing definition for `lto_codegen_create_in_local_context()`. llvm-svn: 224567
* libLTO: Allow linker to choose context of modules and codegenDuncan P. N. Exon Smith2014-11-111-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add API for specifying which `LLVMContext` each `lto_module_t` and `lto_code_gen_t` is in. In particular, this enables the following flow: for (auto &File : Files) { lto_module_t M = lto_module_create_in_local_context(File...); querySymbols(M); lto_module_dispose(M); } lto_code_gen_t CG = lto_codegen_create_in_local_context(); for (auto &File : FilesToLink) { lto_module_t M = lto_module_create_in_codegen_context(File..., CG); lto_codegen_add_module(CG, M); lto_module_dispose(M); } lto_codegen_compile(CG); lto_codegen_write_merged_modules(CG, ...); lto_codegen_dispose(CG); This flow has a few benefits. - Only one module (two if you count the combined module in the code generator) is in memory at a time. - Metadata (and constants) from files that are parsed to query symbols but not linked into the code generator don't pollute the global context. - The first for loop can be parallelized, since each module is in its own context. - When the code generator is disposed, the memory from LTO gets freed. rdar://problem/18767512 llvm-svn: 221733
* Add an option to the LTO code generator to disable vectorization during LTOArnold Schwaighofer2014-10-261-3/+9
| | | | | | | | | | | | | | | | | | | | We used to always vectorize (slp and loop vectorize) in the LTO pass pipeline. r220345 changed it so that we used the PassManager's fields 'LoopVectorize' and 'SLPVectorize' out of the desire to be able to disable vectorization using the cl::opt flags 'vectorize-loops'/'slp-vectorize' which the before mentioned fields default to. Unfortunately, this turns off vectorization because those fields default to false. This commit adds flags to the LTO library to disable lto vectorization which reconciles the desire to optionally disable vectorization during LTO and the desired behavior of defaulting to enabled vectorization. We really want tools to set PassManager flags directly to enable/disable vectorization and not go the route via cl::opt flags *in* PassManagerBuilder.cpp. llvm-svn: 220652
* Update the error handling of lib/Linker.Rafael Espindola2014-10-251-1/+1
| | | | | | Instead of passing a std::string&, use the new diagnostic infrastructure. llvm-svn: 220608
* Remove lto_codegen_set_attr.Rafael Espindola2014-08-011-4/+0
| | | | | | It was never exported, so no functionality change. llvm-svn: 214519
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-061-3/+3
| | | | llvm-svn: 212405
* Change LTOModule`s getTargetTriple and setTargetTriple to use c++ types.Rafael Espindola2014-07-041-1/+1
| | | | llvm-svn: 212343
* Sink undesirable LTO functions into the old C APIAlp Toker2014-07-041-2/+9
| | | | | | | | | We want to encourage users of the C++ LTO API to reuse memory buffers instead of repeatedly opening and reading the same file contents. This reverts commit r212305 and implements a tidier scheme. llvm-svn: 212308
* LTO: rename the various makeLTOModule overloads.Peter Collingbourne2014-07-031-6/+6
| | | | | | | | | This rename makes it easier to identify the specific overload being called in each particular case and makes future refactorings easier. Differential Revision: http://reviews.llvm.org/D4370 llvm-svn: 212302
* Remove unused includes following r211294Alp Toker2014-06-191-2/+0
| | | | llvm-svn: 211297
* Use the c++ APIs.Rafael Espindola2014-06-191-6/+7
| | | | | | No functionality change. llvm-svn: 211294
* Fix gcc -pedantic warning in lto.cpp.Patrik Hagglund2014-05-051-2/+2
| | | | llvm-svn: 207959
* Move LTOModule and LTOCodeGenerator to the llvm namespace.Rafael Espindola2014-05-031-39/+41
| | | | llvm-svn: 207911
* Style update: don't duplicate comments, they were getting out of sync.Rafael Espindola2014-05-031-73/+0
| | | | llvm-svn: 207909
* Add an -mattr option to the gold plugin to support subtarget features in LTOTom Roeder2014-04-251-0/+22
| | | | | | | | | | This adds support for an -mattr option to the gold plugin and to llvm-lto. This allows the caller to specify details of the subtarget architecture, like +aes, or +ssse3 on x86. Note that this requires a change to the include/llvm-c/lto.h interface: it adds a function lto_codegen_set_attr and it increments the version of the interface. llvm-svn: 207279
* Revert "Reapply "LTO: add API to set strategy for -internalize""Duncan P. N. Exon Smith2014-04-021-7/+0
| | | | | | | | | | | This reverts commit r199244. Conflicts: include/llvm-c/lto.h include/llvm/LTO/LTOCodeGenerator.h lib/LTO/LTOCodeGenerator.cpp llvm-svn: 205471
* Refactor TargetOptions initialization into a single place.Eli Bendersky2014-02-191-34/+6
| | | | | | | | | | | | The same code (~20 lines) for initializing a TargetOptions object from CodeGen cmdline flags is duplicated 4 times in 4 different tools. This patch moves it into a utility function. Since the CodeGen/CommandFlags.h file defines cl::opt flags in a header, it's a bit of a touchy situation because we should only link them into tools. So this patch puts the init function in the header. llvm-svn: 201699
* LTO API: add lto_module_create_from_memory_with_path.Manman Ren2014-02-101-0/+11
| | | | | | | | | | | | | This function adds an extra path argument to lto_module_create_from_memory. The path argument will be passed to makeBuffer to make sure the MemoryBuffer has a name and the created module has a module identifier. This is mainly for emitting warning messages from the linker. When we emit warning message on a module, we can use the module identifier. rdar://15985737 llvm-svn: 201114
* Adding new LTO APIs to parse metadata nodes and extract linker options andYunzhong Gao2014-01-211-0/+22
| | | | | | | | dependent libraries from a bitcode module. Differential Revision: http://llvm-reviews.chandlerc.com/D2343 llvm-svn: 199759
* [LTO] Add a hook to map LLVM diagnostics into the clients of LTO.Quentin Colombet2014-01-151-0/+7
| | | | | | | | | | | | | | | | | | | Add a hook in the C API of LTO so that clients of the code generator can set their own handler for the LLVM diagnostics. The handler is defined like this: typedef void (*lto_diagnostic_handler_t)(lto_codegen_diagnostic_severity_t severity, const char *diag, void *ctxt) - severity says how bad this is. - diag is a string that contains the diagnostic message. - ctxt is the registered context for this handler. This hook is more general than the lto_get_error_message, since this function keeps only the latest message and can only be queried when something went wrong (no warning for instance). <rdar://problem/15517596> llvm-svn: 199338
* Reapply "LTO: add API to set strategy for -internalize"Duncan P. N. Exon Smith2014-01-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply r199191, reverted in r199197 because it carelessly broke Other/link-opts.ll. The problem was that calling createInternalizePass("main") would select createInternalizePass(bool("main")) instead of createInternalizePass(ArrayRef<const char *>("main")). This commit fixes the bug. The original commit message follows. Add API to LTOCodeGenerator to specify a strategy for the -internalize pass. This is a new attempt at Bill's change in r185882, which he reverted in r188029 due to problems with the gold linker. This puts the onus on the linker to decide whether (and what) to internalize. In particular, running internalize before outputting an object file may change a 'weak' symbol into an internal one, even though that symbol could be needed by an external object file --- e.g., with arclite. This patch enables three strategies: - LTO_INTERNALIZE_FULL: the default (and the old behaviour). - LTO_INTERNALIZE_NONE: skip -internalize. - LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden visibility. LTO_INTERNALIZE_FULL should be used when linking an executable. Outputting an object file (e.g., via ld -r) is more complicated, and depends on whether hidden symbols should be internalized. E.g., for ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and LTO_INTERNALIZE_HIDDEN can be used otherwise. However, LTO_INTERNALIZE_FULL is inappropriate, since the output object file will eventually need to link with others. lto_codegen_set_internalize_strategy() sets the strategy for subsequent calls to lto_codegen_write_merged_modules() and lto_codegen_compile*(). <rdar://problem/14334895> llvm-svn: 199244
* Revert r199191, "LTO: add API to set strategy for -internalize"NAKAMURA Takumi2014-01-141-7/+0
| | | | | | Please update also Other/link-opts.ll, in next time. llvm-svn: 199197
* LTO: add API to set strategy for -internalizeDuncan P. N. Exon Smith2014-01-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add API to LTOCodeGenerator to specify a strategy for the -internalize pass. This is a new attempt at Bill's change in r185882, which he reverted in r188029 due to problems with the gold linker. This puts the onus on the linker to decide whether (and what) to internalize. In particular, running internalize before outputting an object file may change a 'weak' symbol into an internal one, even though that symbol could be needed by an external object file --- e.g., with arclite. This patch enables three strategies: - LTO_INTERNALIZE_FULL: the default (and the old behaviour). - LTO_INTERNALIZE_NONE: skip -internalize. - LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden visibility. LTO_INTERNALIZE_FULL should be used when linking an executable. Outputting an object file (e.g., via ld -r) is more complicated, and depends on whether hidden symbols should be internalized. E.g., for ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and LTO_INTERNALIZE_HIDDEN can be used otherwise. However, LTO_INTERNALIZE_FULL is inappropriate, since the output object file will eventually need to link with others. lto_codegen_set_internalize_strategy() sets the strategy for subsequent calls to lto_codegen_write_merged_modules() and lto_codegen_compile*(). <rdar://problem/14334895> llvm-svn: 199191
* Re-sort #include lines again, prior to moving headers around.Chandler Carruth2014-01-131-2/+2
| | | | llvm-svn: 199080
* Use LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN instead of the "dso list".Rafael Espindola2013-10-311-4/+0
| | | | | | | | | | | | | | | | | | | | | | There are two ways one could implement hiding of linkonce_odr symbols in LTO: * LLVM tells the linker which symbols can be hidden if not used from native files. * The linker tells LLVM which symbols are not used from other object files, but will be put in the dso symbol table if present. GOLD's API is the second option. It was implemented almost 1:1 in llvm by passing the list down to internalize. LLVM already had partial support for the first option. It is also very similar to how ld64 handles hiding these symbols when *not* doing LTO. This patch then * removes the APIs for the DSO list. * marks LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN all linkonce_odr unnamed_addr global values and other linkonce_odr whose address is not used. * makes the gold plugin responsible for handling the API mismatch. llvm-svn: 193800
* lto.h: Use lto_bool_t instead of int to restore the ABIReid Kleckner2013-10-241-9/+9
| | | | | | | | | | | | This reverts commit r193255 and instead creates an lto_bool_t typedef that points to bool, _Bool, or unsigned char depending on what is available. Only recent versions of MSVC provide a stdbool.h header. Reviewers: rafael.espindola Differential Revision: http://llvm-reviews.chandlerc.com/D2019 llvm-svn: 193377
* llvm-c/lto.h: Avoid use of bool.NAKAMURA Takumi2013-10-231-9/+9
| | | | llvm-svn: 193255
* Optimize linkonce_odr unnamed_addr functions during LTO.Rafael Espindola2013-10-031-0/+4
| | | | | | | | | | | Generalize the API so we can distinguish symbols that are needed just for a DSO symbol table from those that are used from some native .o. The symbols that are only wanted for the dso symbol table can be dropped if llvm can prove every other dso has a copy (linkonce_odr) and the address is not important (unnamed_addr). llvm-svn: 191922
* Fix option parsing in the gold plugin.Rafael Espindola2013-10-021-0/+15
| | | | | | | | | This was broken when options were moved up in r191680. No test because this is specific LLVMgold.so/libLTO.so. Patch by Tom Roeder! llvm-svn: 191829
* Move command line options to the users of libLTO. Fixes --enable-shared build.Rafael Espindola2013-09-301-7/+60
| | | | | | Patch by Richard Sandiford. llvm-svn: 191680
* Move LTO support library to a component, allowing it to be testedPeter Collingbourne2013-09-241-2/+25
| | | | | | more reliably across platforms. Patch by Tom Roeder! llvm-svn: 191343
* Revert 189297, the original commit message is following. Shuxin Yang2013-08-271-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ---- Add new API lto_codegen_compile_parallel(). This API is proposed by Nick Kledzik. The semantic is: -------------------------------------------------------------------------- Generate code for merged module into an array of native object files. On success returns a pointer to an array of NativeObjectFile. The count parameter returns the number of elements in the array. Each element is a pointer/length for a generated mach-o/ELF buffer. The buffer is owned by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, or lto_codegen_compile() is called again. On failure, returns NULL (check lto_get_error_message() for details). extern const struct NativeObjectFile* lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count); --------------------------------------------------------------------------- This API is currently only called on OSX platform. Linux or other Unixes using GNU gold are not supposed to call this function, because on these systems, object files are fed back to linker via disk file instead of memory buffer. In this commit, lto_codegen_compile_parallel() simply calls lto_codegen_compile() to return a single object file. In the near future, this function is the entry point for compilation with partition. Linker can blindly call this function even if partition is turned off; in this case, compiler will return only one object file. llvm-svn: 189386
* Add new API lto_codegen_compile_parallel().Shuxin Yang2013-08-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This API is proposed by Nick Kledzik. The semantic is: -------------------------------------------------------------------------- Generate code for merged module into an array of native object files. On success returns a pointer to an array of NativeObjectFile. The count parameter returns the number of elements in the array. Each element is a pointer/length for a generated mach-o/ELF buffer. The buffer is owned by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, or lto_codegen_compile() is called again. On failure, returns NULL (check lto_get_error_message() for details). extern const struct NativeObjectFile* lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count); --------------------------------------------------------------------------- This API is currently only called on OSX platform. Linux or other Unixes using GNU gold are not supposed to call this function, because on these systems, object files are fed back to linker via disk file instead of memory buffer. In this commit, lto_codegen_compile_parallel() simply calls lto_codegen_compile() to return a single object file. In the near future, this function is the entry point for compilation with partition. Linker can blindly call this function even if partition is turned off; in this case, compiler will return only one object file. llvm-svn: 189297
* Revert r188188 and r188200.Shuxin Yang2013-08-121-13/+0
| | | | | | | | In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review. Thank Eric for fixing a compile-warning. llvm-svn: 188204
* Misc enhancements to LTO:Shuxin Yang2013-08-121-0/+13
| | | | | | | | | | | | | | | | | | | | | 1. Add some helper classes for partitions. They are designed in a way such that the top-level LTO driver will not see much difference with or without partitioning. 2. Introduce work-dir. Now all intermediate files generated during LTO phases will be saved under work-dir. User can specify the workdir via -lto-workdir=/path/to/dir. By default the work-dir will be erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1. TODO: Erase the workdir, if the linker exit prematurely. We are currently not able to remove directory on signal. The support routines simply ignore directory. 3. Add one new API lto_codegen_get_files_need_remove(). Linker and LTO plugin will communicate via this API about which files (including directories) need to removed before linker exit. llvm-svn: 188188
* Change public functions of LTOCodeGenerator from ret-false-on-succ to ↵Shuxin Yang2013-08-071-5/+7
| | | | | | | | | | | ret-true-on-succ. As of this revision, all functions of LTOCodeGenerator are consistent in ret-true-on-succ. Tested on multiple OSes. llvm-svn: 187864
* Split getOpenFile into getOpenFile and getOpenFileSlice.Rafael Espindola2013-07-231-2/+1
| | | | | | | | | | | | | | | | The main observation is that we never need both the filesize and the map size. When mapping a slice of a file, it doesn't make sense to request a null terminator and that would be the only case where the filesize would be used. There are other cleanups that should be done in this area: * A client should not have to pass the size (even an explicit -1) to say if it wants a null terminator or not, so we should probably swap the argument order. * The default should be to not require a null terminator. Very few clients require this, but many end up asking for it just because it is the default. llvm-svn: 186984
* Revert r169656.Bill Wendling2012-12-101-6/+0
| | | | | | | | The linker will call `lto_codegen_add_must_preserve_symbol' on all globals that should be kept around. The linker will pretend that a dylib is being created. <rdar://problem/12528059> llvm-svn: 169770
* Add the `lto_codegen_set_export_dynamic' function.Bill Wendling2012-12-081-0/+6
| | | | | | | | | | | | | | | | | | | | | This function sets the `_exportDynamic' ivar. When that's set, we export all symbols (e.g. we don't run the internalize pass). This is equivalent to the `--export-dynamic' linker flag in GNU land: --export-dynamic When creating a dynamically linked executable, add all symbols to the dynamic symbol table. The dynamic symbol table is the set of symbols which are visible from dynamic objects at run time. If you do not use this option, the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link. If you use dlopen to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself. The Darwin linker will support this via the `-export_dynamic' flag. We should modify clang to support this via the `-rdynamic' flag. llvm-svn: 169656
* Sort the #include lines for tools/...Chandler Carruth2012-12-041-3/+2
| | | | | | | | Again, tools are trickier to pick the main module header for than library source files. I've started to follow the pattern of using LLVMContext.h when it is included as a stub for program source files. llvm-svn: 169252
* Remove lto_codegen_set_whole_program_optimization. It is a work in progress,Rafael Espindola2012-04-161-6/+0
| | | | | | | | | so we don't want it to show up in the stable 3.1 interface. While at it, add a comment about why LTOCodeGenerator manually creates the internalize pass. llvm-svn: 154807
* s/lto_codegen_whole_program_optimization/lto_codegen_set_whole_program_optim ↵Bill Wendling2012-04-091-3/+3
| | | | | | ization/ llvm-svn: 154312
* Add a hook to turn on the internalize pass through the LTO interface.Bill Wendling2012-04-091-0/+6
| | | | llvm-svn: 154306
* Cleanup whitespace and remove unneeded 'extern' keyword on function definitions.Bill Wendling2012-03-311-11/+10
| | | | llvm-svn: 153802
* Cleanup whitespace. Doxygenize comments. And indent to llvm coding standards.Bill Wendling2012-03-301-214/+119
| | | | llvm-svn: 153740
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-1/+1
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Add a lto_codegen_compile_to_file to avoid producing a file, reading it toRafael Espindola2011-03-221-0/+6
| | | | | | memory and writing it back to disk. llvm-svn: 128108
* Add support in the LTO library for loading an object from the middleRafael Espindola2011-03-171-1/+14
| | | | | | of an file. llvm-svn: 127781
* Switch LTO to use MC. This takes the linking of libxul.so from about 7m toRafael Espindola2011-02-241-2/+2
| | | | | | 6m30. llvm-svn: 126426
* Don't open the file again in the gold plugin. To be able to do this, updateRafael Espindola2011-02-081-0/+8
| | | | | | MemoryBuffer::getOpenFile to not close the file descriptor. llvm-svn: 125128
OpenPOWER on IntegriCloud