summaryrefslogtreecommitdiffstats
path: root/llvm/include/llvm-c/lto.h
Commit message (Collapse)AuthorAgeFilesLines
* [LTO][Legacy] Add API for passing LLVM options separatelyFrancis Visoiu Mistrih2019-11-191-1/+14
| | | | | | | | | | | | In order to correctly pass options to LLVM, including options containing spaces which are used as delimiters for multiple options in lto_codegen_debug_options, add a new API: lto_codegen_debug_options_array. Unfortunately, tools/lto has no testing infrastructure yet, so there are no tests associated with this patch. Differential Revision: https://reviews.llvm.org/D70463
* Wrap C APIs with pragmas enforcing -Werror=strict-prototypesDuncan P. N. Exon Smith2019-11-191-6/+4
| | | | | | | | | Force `-Werror=strict-prototypes` so that C API tests fail to compile if we add a non-prototype declaration. This should help avoid regressions like bddecba4b333f7772029b4937d2c34f9f2fda6ca was fixing. https://reviews.llvm.org/D70285 rdar://problem/57203137
* [LTO][Legacy] Add new C inferface to query libcall functionsSteven Wu2019-09-161-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is needed to implemented the same approach as lld (implemented in r338434) for how to handling symbols that can be generated by LTO code generator but not present in the symbol table for linker that uses legacy C APIs. libLTO is in charge of providing the list of symbols. Linker is in charge of implementing the eager loading from static libraries using the list of symbols. rdar://problem/52853974 Reviewers: tejohnson, bd1976llvm, deadalnix, espindola Reviewed By: tejohnson Subscribers: emaste, arichardson, hiraditya, MaskRay, dang, kledzik, mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67568 llvm-svn: 372021
* [NFC][libLTO] Rearrange declaration in lto.hSteven Wu2019-09-131-42/+42
| | | | | | | | | | | | | | | | | | Summary: Rearrange the function declaration in lto.h so they falls in the correct doxygen group. Reviewers: tejohnson, bd1976llvm, deadalnix Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67565 llvm-svn: 371900
* [ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of ↵Ben Dunbobbin2019-06-121-9/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the IRSymtab Dependent libraries support for the legacy api was committed in a broken state (see: https://reviews.llvm.org/D60274). This was missed due to the painful nature of having to integrate the changes into a linker in order to test. This change implements support for dependent libraries in the legacy LTO api: - I have removed the current api function, which returns a single string, and added functions to access each dependent library specifier individually. - To reduce the testing pain, I have made the api functions as thin as possible to maximize coverage from llvm-lto. - When doing ThinLTO the system linker will load the modules lazily when scanning the input files. Unfortunately, when modules are lazily loaded there is no access to module level named metadata. To fix this I have added api functions that allow querying the IRSymtab for the dependent libraries. I hope to expand the api in the future so that, eventually, all the information needed by a client linker during scan can be retrieved from the IRSymtab. Differential Revision: https://reviews.llvm.org/D62935 llvm-svn: 363140
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-171-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+4
| | | | | | | | | | | | | | | | | 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
* Reland r342233: [ThinLTO] Allow setting of maximum cache size with 64-bit numberJames Henderson2018-09-171-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | The original was reverted due to an apparent build-bot test failure, but it looks like this is just a flaky test. Also added a C-interface function for large values, and updated llvm-lto's --thinlto-cache-max-size-bytes switch to take a type larger than int. The maximum cache size in terms of bytes is a 64-bit number. However, the methods to set it only took unsigned previously, which meant that the maximum cache size could not be specified above 4GB. That's quite small compared to the output of some projects, so it makes sense to provide the ability to set larger values in that field. We also needed a C-interface function that provides a greater range than the existing thinlto_codegen_set_cache_size_bytes, which also only takes an unsigned, so this change also adds hinlto_codegen_set_cache_size_megabytes. Reviewed by: mehdi_amini, tejohnson, steven_wu Differential Revision: https://reviews.llvm.org/D52023 llvm-svn: 342366
* Revert r342233.James Henderson2018-09-141-11/+1
| | | | | | | | This caused LLD test failures, which I've been unable to reproduce. Reverting to allow for further investigation next week. llvm-svn: 342244
* [ThinLTO]Allow setting of maximum cache size with 64-bit numberJames Henderson2018-09-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | Also added a C-interface function for large values, and updated llvm-lto's --thinlto-cache-max-size-bytes switch to take a type larger than int. The maximum cache size in terms of bytes is a 64-bit number. However, the methods to set it only took unsigned previously, which meant that the maximum cache size could not be specified above 4GB. That's quite small compared to the output of some projects, so it makes sense to provide the ability to set larger values in that field. We also needed a C-interface function that provides a greater range than the existing thinlto_codegen_set_cache_size_bytes, which also only takes an unsigned, so this change also adds hinlto_codegen_set_cache_size_megabytes. Reviewed by: mehdi_amini, tejohnson, steven_wu Differential Revision: https://reviews.llvm.org/D52023 llvm-svn: 342233
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-4/+4
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [ThinLTO] Added a couple of C LTO API interfaces to control the cache policy.Ekaterina Romanova2018-03-021-1/+23
| | | | | | | | | | - thinlto_codegen_set_cache_size_bytes to control the absolute size of cache directory. - thinlto_codegen_set_cache_size_files the size and amount of files in cache directory. These functions have been supported in C++ LTO API for a long time, but were absent in C LTO API. Differential Revision: https://reviews.llvm.org/D42446 llvm-svn: 326537
* Allow 0 to be a valid value pruning interval in C LTO API. Value 0 will ↵Ekaterina Romanova2018-02-151-1/+1
| | | | | | cause garbage collector to run. This matches the behavior in C++ LTO API. llvm-svn: 325303
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-01-231-1/+1
| | | | | | "the the" -> "the" llvm-svn: 323176
* [ThinLTO][CachePruning] explicitly disable pruningBen Dunbobbin2017-12-221-4/+4
| | | | | | | | | | | In https://reviews.llvm.org/rL321077 and https://reviews.llvm.org/D41231 I fixed a regression in the c-api which prevented the pruning from being *effectively* disabled. However this approach, helpfully recommended by @labath, is cleaner. It is also nice to remove the weasel words about effectively disabling from the api comments. Differential Revision: https://reviews.llvm.org/D41497 llvm-svn: 321376
* [ThinLTO][C-API] Correct api commentsBen Dunbobbin2017-12-191-9/+9
| | | | | | | | | | | | Negative values never disabled the pruning - they simply set high values for the pruning interval. The behaviour now is that negative values set the maximum pruning interval (which appears to have been the intention from the start) see https://reviews.llvm.org/D41231. I have adjusted the comments to reflect this, removed any inaccurate statements, and corrected any typos I spotted in the English. Differential Revision: https://reviews.llvm.org/D41279 llvm-svn: 321078
* Reorganize libLTO C API header lto.h (NFC)Mehdi Amini2017-04-081-74/+70
| | | | | | This just makes it easier to follow the Doxygen blocks llvm-svn: 299814
* [ThinLTO] Add an API to trigger file-based API for returning objects to the ↵Mehdi Amini2016-12-141-1/+35
| | | | | | | | | | | | | | | | | | | | linker Summary: The motivation is to support better the -object_path_lto option on Darwin. The linker needs to write down the generate object files on disk for later use by lldb or dsymutil (debug info are not present in the final binary). We're moving this into libLTO so that we can be smarter when a cache is enabled and hard-link when possible instead of duplicating the files. Reviewers: tejohnson, deadalnix, pcc Subscribers: dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D27507 llvm-svn: 289631
* Propery format doccomment in lto.h . NFCAmaury Sechet2016-07-261-4/+4
| | | | llvm-svn: 276725
* Do not use bool in C header lto.h, use lto_bool_t insteadMehdi Amini2016-07-111-1/+2
| | | | llvm-svn: 275130
* Add a libLTO API to query a memory buffer and check if it contains ObjC ↵Mehdi Amini2016-07-111-5/+13
| | | | | | | | | | | categories The linker supports a feature to force load an object from a static archive if it defines an Objective-C category. This API supports this feature by looking at every section in the module to find if a category is defined in the module. llvm-svn: 275125
* ThinLTOCodeGenerator: ignore 0 values for the cache settings.Mehdi Amini2016-05-091-4/+5
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268890
* Provide some default values for the ThinLTO Cache pruningMehdi Amini2016-05-031-3/+6
| | | | | | | | This control how the cache is pruned. The cache still has to be explicitely enabled/disabled by providing a path. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268393
* Add a libLTO API to stop/restart ThinLTO between optimizations and CodeGenMehdi Amini2016-04-011-1/+19
| | | | | | | | This allows the linker to instruct ThinLTO to perform only the optimization part or only the codegen part of the process. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265113
* Fix Clang-tidy modernize-deprecated-headers warnings in some files; other ↵Eugene Zelenko2016-03-281-15/+5
| | | | | | | | minor fixes. Differential revision: http://reviews.llvm.org/D18469 llvm-svn: 264598
* Const-correctness in libLTOMehdi Amini2016-03-191-1/+1
| | | | | | | | Looks like I was sloppy when bridging to C. Thanks D. Blaikie for noticing! From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263885
* Use lto_bool_t instead of a raw `bool` (fixup for r262977).Sean Silva2016-03-091-1/+1
| | | | | | | Hopefully this should bring llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast back to life. llvm-svn: 262994
* void foo() is not a valid C prototype, one has to write void foo(void)Mehdi Amini2016-03-091-1/+1
| | | | | | | Remove a warning introduced in r262977 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 262990
* libLTO: add a ThinLTOCodeGenerator on the model of LTOCodeGenerator.Mehdi Amini2016-03-091-2/+219
| | | | | | | | | | | | | | | | | This is intended to provide a parallel (threaded) ThinLTO scheme for linker plugin use through the libLTO C API. The intent of this patch is to provide a first implementation as a proof-of-concept and allows linker to start supporting ThinLTO by definiing the libLTO C API. Some part of the libLTO API are left unimplemented yet. Following patches will add support for these. The current implementation can link all clang/llvm binaries. Differential Revision: http://reviews.llvm.org/D17066 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 262977
* LTO: Simplify merged module ownership.Peter Collingbourne2015-08-241-2/+2
| | | | | | | | | | | This change moves LTOCodeGenerator's ownership of the merged module to a field of type std::unique_ptr<Module>. This helps simplify parts of the code and clears the way for the module to be consumed by LLVM CodeGen (see D12132 review comments). Differential Revision: http://reviews.llvm.org/D12205 llvm-svn: 245891
* LTO: expose LTO_SYMBOL_ALIAS, which indicates that the symbol is an alias.Peter Collingbourne2015-07-041-2/+3
| | | | | | | | This is needed for COFF linkers to distinguish between weak external aliases and regular symbols with LLVM weak linkage, which are represented as strong symbols in COFF. llvm-svn: 241389
* lto: Clean up C libLTO interfaces pertaining to linker flags.Peter Collingbourne2015-06-291-39/+5
| | | | | | | | | Specifically, remove the dependent library interface and replace the existing linker option interface with a new one that returns a single list of flags. Differential Revision: http://reviews.llvm.org/D10820 llvm-svn: 241018
* Teach LTOModule to emit linker flags for dllexported symbols, plus interface ↵Peter Collingbourne2015-06-291-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cleanup. This change unifies how LTOModule and the backend obtain linker flags for globals: via a new TargetLoweringObjectFile member function named emitLinkerFlagsForGlobal. A new function LTOModule::getLinkerOpts() returns the list of linker flags as a single concatenated string. This change affects the C libLTO API: the function lto_module_get_*deplibs now exposes an empty list, and lto_module_get_*linkeropts exposes a single element which combines the contents of all observed flags. libLTO should never have tried to parse the linker flags; it is the linker's job to do so. Because linkers will need to be able to parse flags in regular object files, it makes little sense for libLTO to have a redundant mechanism for doing so. The new API is compatible with the old one. It is valid for a user to specify multiple linker flags in a single pragma directive like this: #pragma comment(linker, "/defaultlib:foo /defaultlib:bar") The previous implementation would not have exposed either flag via lto_module_get_*deplibs (as the test in TargetLoweringObjectFileCOFF::getDepLibFromLinkerOpt was case sensitive) and would have exposed "/defaultlib:foo /defaultlib:bar" as a single flag via lto_module_get_*linkeropts. This may have been a bug in the implementation, but it does give us a chance to fix the interface. Differential Revision: http://reviews.llvm.org/D10548 llvm-svn: 241010
* LTO: expose LTO_SYMBOL_COMDAT flag, which indicates that the definition is ↵Peter Collingbourne2015-06-111-1/+2
| | | | | | | | | | | | part of a comdat group. Reviewers: rafael Subscribers: llvm-commits, ruiu Differential Revision: http://reviews.llvm.org/D10330 llvm-svn: 239559
* LTO: Add API to choose whether to embed uselistsDuncan P. N. Exon Smith2015-04-271-1/+13
| | | | | | | | | | | | | | | | | | | | | | Reverse libLTO's default behaviour for preserving use-list order in bitcode, and add API for controlling it. The default setting is now `false` (don't preserve them), which is consistent with `clang`'s default behaviour. Users of libLTO should call `lto_codegen_should_embed_uselists(CG,true)` prior to calling `lto_codegen_write_merged_modules()` whenever the output file isn't part of the production workflow in order to reproduce results with subsequent calls to `llc`. (I haven't added tests since `llvm-lto` (the test tool for LTO) doesn't support bitcode output, and even if it did: there isn't actually a good way to test whether a tool has passed the flag. If the order is already "natural" (if the order will already round-trip) then no use-list directives are emitted at all. At some point I'll circle back to add tests to `llvm-as` (etc.) that they actually respect the flag, at which point I can somehow add a test here as well.) llvm-svn: 235943
* LTO: Correct some doxygen comments about API availabilityDuncan P. N. Exon Smith2015-04-271-3/+3
| | | | | | | | | | These look like copy/paste errors, and shouldn't have the "prior to" qualifier. Each API was introduced at the given values of `LTO_API_VERSION`. The "prior to" in other doxygen comments is because I couldn't easily differentiate between versions 1 and 2 when I added these comments. llvm-svn: 235925
* [LTO API] add lto_codegen_set_should_internalize.Manman Ren2015-04-171-1/+11
| | | | | | | | | | | When debugging LTO issues with ld64, we use -save-temps to save the merged optimized bitcode file, then invoke ld64 again on the single bitcode file. The saved bitcode file is already internalized, so we can call lto_codegen_set_should_internalize and skip running internalization again. rdar://20227235 llvm-svn: 235211
* [LTO API] add lto_codegen_set_module to set the destination module.Manman Ren2015-02-241-1/+12
| | | | | | | | | | | | | | | | | | When debugging LTO issues with ld64, we use -save-temps to save the merged optimized bitcode file, then invoke ld64 again on the single bitcode file to speed up debugging code generation passes and ld64 stuff after code generation. llvm linking a single bitcode file via lto_codegen_add_module will generate a different bitcode file from the single input. With the newly-added lto_codegen_set_module, we can make sure the destination module is the same as the input. lto_codegen_set_module will transfer the ownship of the module to code generator. rdar://19024554 llvm-svn: 230290
* Fix warning: "function declaration isn’t a prototype"Rafael Espindola2015-02-041-1/+1
| | | | llvm-svn: 228139
* Fix duplicated symbol error.Rafael Espindola2015-02-031-3/+1
| | | | llvm-svn: 228012
* [LTO API] split lto_codegen_compile to lto_codegen_optimize andManman Ren2015-02-031-1/+38
| | | | | | | | | | | | | | | | | | | lto_codegen_compile_optimized. Also add lto_api_version. Before this commit, we can only dump the optimized bitcode after running lto_codegen_compile, but it includes some impacts of running codegen passes, one example is StackProtector pass. We will get assertion failure when running llc on the optimized bitcode, because StackProtector is effectively run twice. After splitting lto_codegen_compile, the linker can choose to dump the bitcode before running lto_codegen_compile_optimized. lto_api_version is added so ld64 can check for runtime-availability of the new API. rdar://19565500 llvm-svn: 228000
* libLTO: Allow linker to choose context of modules and codegenDuncan P. N. Exon Smith2014-11-111-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove lto_codegen_set_attr.Rafael Espindola2014-08-011-9/+1
| | | | | | It was never exported, so no functionality change. llvm-svn: 214519
* Move LTOModule and LTOCodeGenerator to the llvm namespace.Rafael Espindola2014-05-031-2/+2
| | | | llvm-svn: 207911
* Style update: don't duplicate comments, they were getting out of sync.Rafael Espindola2014-05-031-2/+3
| | | | llvm-svn: 207909
* Add an -mattr option to the gold plugin to support subtarget features in LTOTom Roeder2014-04-251-1/+9
| | | | | | | | | | 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
* Teach llvm-lto to respect the given RelocModel.James Molloy2014-04-141-1/+2
| | | | | | Patch by Nick Tomlinson! llvm-svn: 206177
* Revert "Reapply "LTO: add API to set strategy for -internalize""Duncan P. N. Exon Smith2014-04-021-19/+0
| | | | | | | | | | | This reverts commit r199244. Conflicts: include/llvm-c/lto.h include/llvm/LTO/LTOCodeGenerator.h lib/LTO/LTOCodeGenerator.cpp llvm-svn: 205471
* Add 'remark' diagnostic type in LLVMTobias Grosser2014-02-281-4/+5
| | | | | | | | | | | | A 'remark' is information that is not an error or a warning, but rather some additional information provided to the user. In contrast to a 'note' a 'remark' is an independent diagnostic, whereas a 'note' always depends on another diagnostic. A typical use case for remark nodes is information provided to the user, e.g. information provided by the vectorizer about loops that have been vectorized. llvm-svn: 202474
* LTO API: add lto_module_create_from_memory_with_path.Manman Ren2014-02-101-1/+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
OpenPOWER on IntegriCloud