Commit Graph

537 Commits

Author SHA1 Message Date
Francis Visoiu Mistrih bffdee8ef3 [LTO][Legacy] Add API for passing LLVM options separately
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
2019-11-19 16:30:37 -08:00
Steven Wu 34d80461ff [LTO][Legacy] Add new C inferface to query libcall functions
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
2019-09-16 18:49:54 +00:00
Jonas Devlieghere 0eaee545ee [llvm] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013
2019-08-15 15:54:37 +00:00
Tom Stellard a196469e67 cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macros
Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.

Reviewers: beanz, smeenai

Reviewed By: beanz

Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D64580

llvm-svn: 365902
2019-07-12 14:40:18 +00:00
Ben Dunbobbin 52d3e4b4aa [Legacy LTO] Fix build bots: r363140: Fix export name
llvm-svn: 363151
2019-06-12 12:17:49 +00:00
Ben Dunbobbin 564d248ec2 [ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of 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
2019-06-12 11:07:56 +00:00
Daniel Sanders 3e4acaabb9 Break false dependencies on target libraries
Summary:
For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with
some combination of AllTargets* so that they depend on specific components
of a target backend rather than all of it. The overall effect of this is
that, for example, tools like opt no longer falsely depend on the
disassembler, while tools like llvm-ar no longer depend on the code
generator.

There's a couple quirks to point out here:
* AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil
  seem to need it which I was surprised by.
* llvm-xray linked to all the backends but doesn't seem to need any of them.
  It builds and passes the tests so that seems to be correct.
* I left gold out as it's not built when binutils is not available so I'm
  unable to test it

Reviewers: bogner, JDevlieghere

Reviewed By: bogner

Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62331

llvm-svn: 361567
2019-05-23 23:02:56 +00:00
Ben Dunbobbin 1d16515fb4 [ELF] Implement Dependent Libraries Feature
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
2019-05-17 03:44:15 +00:00
Chandler Carruth 2946cd7010 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 08:50:56 +00:00
Steven Wu 6562bd9ee0 [libLTO] Expose LLVMCreateDisasmCPUFeatures from libLTO
The export file of libLTO should has all the interfaces declared in
llvm-c/lto.h and llvm-c/Disassembler.h but LLVMCreateDisasmCPUFeatures
is missing from the list. Export the C API to be consistant.

llvm-svn: 343124
2018-09-26 16:47:35 +00:00
James Henderson e29e40854b Reland r342233: [ThinLTO] Allow setting of maximum cache size with 64-bit number
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
2018-09-17 10:21:26 +00:00
James Henderson 13f426304f Revert r342233.
This caused LLD test failures, which I've been unable to reproduce.

Reverting to allow for further investigation next week.

llvm-svn: 342244
2018-09-14 16:48:47 +00:00
James Henderson 48c0688a36 [ThinLTO]Allow setting of maximum cache size with 64-bit number
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
2018-09-14 12:51:19 +00:00
Nico Weber 712e8d29c4 s/LLVM_ON_WIN32/_WIN32/, llvm
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too.  Just use the
default macro instead of a reinvented one.

See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.

This moves over all uses of the macro, but doesn't remove the definition
of it in (llvm-)config.h yet.

llvm-svn: 331127
2018-04-29 00:45:03 +00:00
David Blaikie 4333f9700d Rename *CommandFlags.def to *CommandFlags.inc
These aren't the .def style files used in LLVM that require a macro
defined before their inclusion - they're just basic non-modular includes
to stamp out command line flag variables.

llvm-svn: 329840
2018-04-11 18:49:37 +00:00
Ekaterina Romanova b8aeec46b7 [ThinLTO] Added a couple of C LTO API interfaces to control the cache policy.
- 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
2018-03-02 03:51:27 +00:00
David Blaikie c14bfec487 Rename CommandFlags.h -> CommandFlags.def
Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what they should be) so can't be included more than once in a
program.

llvm-svn: 319082
2017-11-27 19:43:58 +00:00
Vivek Pandya b5ab895e2a This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352
It enables OptimizationRemarkEmitter::allowExtraAnalysis and MachineOptimizationRemarkEmitter::allowExtraAnalysis to return true not only for -fsave-optimization-record but when specific remarks are requested with
command line options.
The diagnostic handler used to be callback now this patch adds a class
DiagnosticHandler. It has virtual method to provide custom diagnostic handler
and methods to control which particular remarks are enabled. 
However LLVM-C API users can still provide callback function for diagnostic handler.

llvm-svn: 313390
2017-09-15 20:10:09 +00:00
Vivek Pandya df8598dcc4 This reverts r313381
llvm-svn: 313387
2017-09-15 19:53:54 +00:00
Vivek Pandya 00d887447b This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352
It enables OptimizationRemarkEmitter::allowExtraAnalysis and MachineOptimizationRemarkEmitter::allowExtraAnalysis to return true not only for -fsave-optimization-record but when specific remarks are requested with
command line options.
The diagnostic handler used to be callback now this patch adds a class
DiagnosticHandler. It has virtual method to provide custom diagnostic handler
and methods to control which particular remarks are enabled. 
However LLVM-C API users can still provide callback function for diagnostic handler.

llvm-svn: 313382
2017-09-15 19:30:59 +00:00
Simon Pilgrim 68168d17b9 Spelling mistakes in comments. NFCI.
Based on corrections mentioned in patch for clang for PR27635

llvm-svn: 299072
2017-03-30 12:59:53 +00:00
Mehdi Amini b5a46c1f45 Add support for -fno-builtin to LTO and ThinLTO to libLTO
Reviewers: tejohnson, pcc

Subscribers: Prazek, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D30791

llvm-svn: 298936
2017-03-28 18:55:44 +00:00
Mehdi Amini cc7fbf718d [ThinLTO] Honor -O{0,1,2,4} passed through the libLTO interface for ThinLTO
This was hardcoded to be O3 till now, without any way to change it
without changing the code.

llvm-svn: 290682
2016-12-28 19:37:16 +00:00
Mehdi Amini 8e13bc4562 [ThinLTO] Add an API to trigger file-based API for returning objects to the 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
2016-12-14 04:56:42 +00:00
Chris Bieneman caf299ffe1 [CMake] LTO depends on intrinsics_gen
lto.cpp has the following include chain:

llvm/Bitcode/BitcodeReader.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means LTO needs to depend on intrinsics_gen.

llvm-svn: 287393
2016-11-18 23:03:51 +00:00
Peter Collingbourne cd513a41c1 Bitcode: Clean up error handling for certain bitcode query functions.
The functions getBitcodeTargetTriple(), isBitcodeContainingObjCCategory(),
getBitcodeProducerString() and hasGlobalValueSummary() now return errors
via their return value rather than via the diagnostic handler.

To make this work, re-implement these functions using non-member functions
so that they can be used without the LLVMContext required by BitcodeReader.

Differential Revision: https://reviews.llvm.org/D26532

llvm-svn: 286623
2016-11-11 19:50:24 +00:00
Teresa Johnson ad17679abd Split Bitcode/ReaderWriter.h into separate reader and writer headers
Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and BitcodeWriter.h.

This is to address Chandler's concern about sharing the same API header
between multiple libraries (BitReader and BitWriter). That concern is
why we create a single bitcode library in our downstream build of clang,
which led to r286297 being reverted as it added a dependency that
created a cycle only when there is a single bitcode library (not two as
in upstream).

Reviewers: mehdi_amini

Subscribers: dlj, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D26502

llvm-svn: 286566
2016-11-11 05:34:58 +00:00
Malcolm Parsons 06ac79c210 Fix Clang-tidy readability-redundant-string-cstr warnings
Reviewers: beanz, lattner, jlebar

Subscribers: jholewinski, llvm-commits, mehdi_amini

Differential Revision: https://reviews.llvm.org/D26235

llvm-svn: 285832
2016-11-02 16:43:50 +00:00
Mehdi Amini dc5a507c92 Recommit "Use StringRef in LTOModule implementation (NFC)""
This reverts commit r283456 and reapply r282997, with explicitly
zeroing the struct member to workaround a bug in MSVC2013 with
zero-initialization: https://connect.microsoft.com/VisualStudio/feedback/details/802160

llvm-svn: 283581
2016-10-07 19:05:14 +00:00
Mehdi Amini a5ee89863c Revert "Use StringRef in LTOModule implementation (NFC)"
This reverts commit r282997, a windows bot is asserting in
one test apparently.

llvm-svn: 283456
2016-10-06 15:12:22 +00:00
Mehdi Amini 05cfdd0800 Use StringRef in LTOModule implementation (NFC)
llvm-svn: 282997
2016-10-01 01:18:16 +00:00
Peter Collingbourne 5c73220fa5 Move legacy LTO interface headers to legacy/ directory.
Differential Revision: https://reviews.llvm.org/D22173

llvm-svn: 275476
2016-07-14 21:21:16 +00:00
NAKAMURA Takumi 99933f1b51 Fix libdeps in r275125. LTO tools require BitReader.
llvm-svn: 275148
2016-07-12 03:01:22 +00:00
Mehdi Amini e75aa6f674 Add a libLTO API to query a memory buffer and check if it contains ObjC 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
2016-07-11 23:10:18 +00:00
Rafael Espindola 8c34dd8257 Delete Reloc::Default.
Having an enum member named Default is quite confusing: Is it distinct
from the others?

This patch removes that member and instead uses Optional<Reloc> in
places where we have a user input that still hasn't been maped to the
default value, which is now clear has no be one of the remaining 3
options.

llvm-svn: 269988
2016-05-18 22:04:49 +00:00
Duncan P. N. Exon Smith 247e636dc7 LTO: Use a common LibLTOCodeGenerator::init, NFC
llvm-svn: 266538
2016-04-16 22:25:36 +00:00
Mehdi Amini 03b42e41bf Remove every uses of getGlobalContext() in LLVM (but the C API)
At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.

This is the first part of http://reviews.llvm.org/D19094

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266379
2016-04-14 21:59:01 +00:00
Mehdi Amini 43b657b5c7 Add a libLTO API to stop/restart ThinLTO between optimizations and CodeGen
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
2016-04-01 06:47:02 +00:00
Mehdi Amini c286b9f0f4 Const-correctness in libLTO
Looks like I was sloppy when bridging to C.
Thanks D. Blaikie for noticing!

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263885
2016-03-19 21:28:18 +00:00
Mehdi Amini 39d1d52d3a Fix a const_cast related warning in GCC in the C API for libLTO
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263870
2016-03-19 01:24:23 +00:00
Mehdi Amini 3ed41d6aa4 void foo() is not a valid C prototype, one has to write void foo(void)
Remove a warning introduced in r262977

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262990
2016-03-09 02:36:09 +00:00
Mehdi Amini 7c4a1a8d48 libLTO: add a ThinLTOCodeGenerator on the model of LTOCodeGenerator.
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
2016-03-09 01:37:22 +00:00
Petr Pavlu 7ad9ec9fcf [LTO] Fix error reporting from lto_module_create_in_local_context()
Function lto_module_create_in_local_context() would previously
rely on the default LLVMContext being created for it by
LTOModule::makeLTOModule(). This context exits the program on
error and is not arranged to update sLastStringError in
tools/lto/lto.cpp.

Function lto_module_create_in_local_context() now creates an
LLVMContext by itself, sets it up correctly to its needs and then
passes it to LTOModule::createInLocalContext() which takes
ownership of the context and keeps it present for the lifetime of
the returned LTOModule.

Function LTOModule::makeLTOModule() is modified to take a
reference to LLVMContext (instead of a pointer) and no longer
creates a default context when nullptr is passed to it. Method
LTOModule::createInContext() that takes a pointer to LLVMContext
is removed because it allows to pass a nullptr to it. Instead
LTOModule::createFromBuffer() (that takes a reference to
LLVMContext) should be used.

Differential Revision: http://reviews.llvm.org/D17715

llvm-svn: 262330
2016-03-01 13:13:49 +00:00
Chris Bieneman 142f4cac26 [CMake] Assigning the LTO component to lto.h
This makes it so lto.h is installed when you run the install-LTO target.

llvm-svn: 262066
2016-02-26 21:07:02 +00:00
Reid Kleckner 7c6b5e15da Add missing raw_ostream include
Prior to r259115 this was coming via LTOModule.h and MCContext.h.

Apparently this target is not built by 'check'. =(

llvm-svn: 259124
2016-01-29 00:03:34 +00:00
Chris Bieneman e49730d4ba Remove autoconf support
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi

Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark

Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D16471

llvm-svn: 258861
2016-01-26 21:29:08 +00:00
Petr Pavlu eba3039238 [LTO] Fix error reporting when a file passed to libLTO is invalid or non-existent
This addresses PR26060 where function lto_module_create() could return nullptr
but lto_get_error_message() returned an empty string.

The error() call after LTOModule::createFromFile() in llvm-lto is then removed
because any error from this function should go through the diagnostic handler in
llvm-lto which will exit the program. The error() call was added because this
previously did not happen when the file was non-existent. This is fixed by the
patch. (The situation that llvm-lto reports an error when the input file does
not exist is tested by llvm/tools/llvm-lto/error.ll).

Differential Revision: http://reviews.llvm.org/D16106

llvm-svn: 258298
2016-01-20 09:03:42 +00:00
Steven Wu b5104b5884 Fix the order of destructors in LibLTOCodeGenerator
Summary:
The order of destructors in LTOCodeGenerator gets changed in r254696.
It is possible for LTOCodeGenerator to have a MergedModule created in
the OwnedContext, in which case the module must be destructed before
the context.

Reviewers: rafael, dexonsmith

Subscribers: llvm-commits, joker.eph

Differential Revision: http://reviews.llvm.org/D15346

llvm-svn: 255092
2015-12-09 03:37:51 +00:00
Rafael Espindola a7612b4fac Modernize the C++ APIs for creating LTO modules.
This is a continuation of r253367.

These functions return is owned by the caller, so they return
std::unique_ptr now.

The call can fail, so the return is wrapped in ErrorOr.

They have a context where to report diagnostics, so they don't need to
take a string out parameter.

With this there are no call to getGlobalContext in lib/LTO.

llvm-svn: 254721
2015-12-04 16:14:31 +00:00
Rafael Espindola 7b8a24e5bb Move a call to getGlobalContext out of lib/LTO.
llvm-svn: 254696
2015-12-04 02:42:28 +00:00