summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-2/+2
| | | | | | Instead of passing a std::string&, use the new diagnostic infrastructure. llvm-svn: 220608
* LTO: Document the Boolean argument from r218784Duncan P. N. Exon Smith2014-10-021-1/+2
| | | | llvm-svn: 218907
* LTO: Ignore disabled diagnostic remarksDuncan P. N. Exon Smith2014-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | r206400 and r209442 added remarks that are disabled by default. However, if a diagnostic handler is registered, the remarks are sent unfiltered to the handler. This is the right behaviour for clang, since it has its own filters. However, the diagnostic handler exposed in the LTO API receives only the severity and message. It doesn't have the information to filter by pass name. For LTO, disabled remarks should be filtered by the producer. I've changed `LLVMContext::setDiagnosticHandler()` to take a `bool` argument indicating whether to respect the built-in filters. This defaults to `false`, so other consumers don't have a behaviour change, but `LTOCodeGenerator::setDiagnosticHandler()` sets it to `true`. To make this behaviour testable, I added a `-use-diagnostic-handler` command-line option to `llvm-lto`. This fixes PR21108. llvm-svn: 218784
* LTO: introduce object file-based on-disk module format.Peter Collingbourne2014-09-181-13/+30
| | | | | | | | | | | | | | | | | | This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
* Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola2014-09-101-1/+1
| | | | | | | | | | | | | With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
* unique_ptrify LTOCodeGenerator::NativeObjectFileDavid Blaikie2014-09-021-7/+2
| | | | llvm-svn: 216927
* Return a std::unique_ptr when creating a new MemoryBuffer.Rafael Espindola2014-08-271-2/+1
| | | | llvm-svn: 216583
* Fix some cases were ArrayRefs were being passed by reference. Also remove ↵Craig Topper2014-08-271-1/+1
| | | | | | 'const' from some other ArrayRef uses since its implicitly const already. llvm-svn: 216524
* Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola2014-08-261-9/+3
| | | | | | | | | | | | | The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
* Simplify LTOModule::makeLTOModule a bit. NFC.Rafael Espindola2014-08-261-3/+1
| | | | | | | Just call parseBitcodeFile instead of getLazyBitcodeModule followed by materializeAllPermanently. llvm-svn: 216461
* Modernize raw_fd_ostream's constructor a bit.Rafael Espindola2014-08-251-3/+3
| | | | | | | | | | Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error. A create static method would be even better, but this patch is already a bit too big. llvm-svn: 216393
* Move some logic to populateLTOPassManager.Rafael Espindola2014-08-211-22/+11
| | | | | | | This will avoid code duplication in the next commit which calls it directly from the gold plugin. llvm-svn: 216211
* Respect LibraryInfo in populateLTOPassManager and use it. NFC.Rafael Espindola2014-08-211-3/+2
| | | | llvm-svn: 216203
* Handle inlining in populateLTOPassManager like in populateModulePassManager.Rafael Espindola2014-08-211-1/+3
| | | | | | No functionality change. llvm-svn: 216178
* Move DisableGVNLoadPRE from populateLTOPassManager to PassManagerBuilder.Rafael Espindola2014-08-211-3/+5
| | | | llvm-svn: 216174
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-2/+2
| | | | | | needing to mention the size. llvm-svn: 216158
* Silencing a -Wcast-qual warning. NFC.Aaron Ballman2014-08-201-1/+1
| | | | llvm-svn: 216068
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-2/+2
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-2/+2
| | | | | | needing to mention the size. llvm-svn: 215868
* Return a std::uinque_ptr. Every caller was already using one.Rafael Espindola2014-08-171-3/+4
| | | | llvm-svn: 215858
* Don't internalize all but main by default.Rafael Espindola2014-08-051-4/+2
| | | | | | | | | | | | | | | This is mostly a cleanup, but it changes a fairly old behavior. Every "real" LTO user was already disabling the silly internalize pass and creating the internalize pass itself. The difference with this patch is for "opt -std-link-opts" and the C api. Now to get a usable behavior out of opt one doesn't need the funny looking command line: opt -internalize -disable-internalize -internalize-public-api-list=foo,bar -std-link-opts llvm-svn: 214919
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-042-6/+11
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Attempt at fixing the windows dll build.Rafael Espindola2014-07-301-1/+1
| | | | | | | It looks like only direct (i.e., explicitly listed) dependencies are scanned. llvm-svn: 214361
* Refactor duplicated code.Rafael Espindola2014-07-301-23/+2
| | | | llvm-svn: 214328
* Add the missing hasLinkOnceODRLinkage predicate.Rafael Espindola2014-07-301-3/+1
| | | | llvm-svn: 214312
* AArch64: remove arm64 triple enumerator.Tim Northover2014-07-232-4/+2
| | | | | | | | | | | | Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
* MergedLoadStoreMotion passGerolf Hoflehner2014-07-181-0/+1
| | | | | | | | | | | Merges equivalent loads on both sides of a hammock/diamond and hoists into into the header. Merges equivalent stores on both sides of a hammock/diamond and sinks it to the footer. Can enable if conversion and tolerate better load misses and store operand latencies. llvm-svn: 213396
* Prune Redundant libdeps in CMake's target_link_libraries and LLVMBuild.txt.NAKAMURA Takumi2014-07-151-1/+1
| | | | | | I checked this with Release+Asserts on x86_64-mingw32. Please restore partially if this were overkill. llvm-svn: 213064
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-062-13/+15
| | | | llvm-svn: 212405
* Revert "Convert a few std::strings to StringRef."Rafael Espindola2014-07-041-2/+2
| | | | | | | | | This reverts commit r212342. We can get a StringRef into the current Record, but not one in the bitcode itself since the string is compressed in it. llvm-svn: 212356
* Ignore llvm specific symbols in the LTOModule.Rafael Espindola2014-07-041-0/+3
| | | | | | | | | | These are the llvm.* globals and functions. I don't think it is possible to test this directly since llvm-lto is not a full linker and will not report duplicated symbols, but this fixes bootstrap with gold and lto enabled. llvm-svn: 212354
* Implement LTOModule on top of IRObjectFile.Rafael Espindola2014-07-042-127/+76
| | | | | | | | | | | | | IRObjectFile provides all the logic for producing mangled names and getting symbols from inline assembly. LTOModule then adds logic for linking specific tasks, like constructing llvm.compiler_user or extracting linker options from the bitcode. The rule of the thumb is that IRObjectFile has the functionality that is needed by both LTO and llvm-ar. llvm-svn: 212349
* Avoid mangling names twice. No functionality change.Rafael Espindola2014-07-041-18/+24
| | | | llvm-svn: 212348
* Convert a few std::strings to StringRef.Rafael Espindola2014-07-041-2/+2
| | | | llvm-svn: 212342
* Fix prefix comparison from r212308Alp Toker2014-07-041-1/+2
| | | | llvm-svn: 212310
* Sink undesirable LTO functions into the old C APIAlp Toker2014-07-041-24/+3
| | | | | | | | | 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
* Modify LTOModule::isTargetMatch to take a StringRef instead of a MemoryBuffer.Peter Collingbourne2014-07-031-8/+8
| | | | llvm-svn: 212305
* LTO: rename the various makeLTOModule overloads.Peter Collingbourne2014-07-031-16/+13
| | | | | | | | | 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
* Use std::unique_ptr to manage memory. No functionality change.Rafael Espindola2014-07-031-13/+14
| | | | llvm-svn: 212299
* LTO depends on Object now.Rafael Espindola2014-07-031-1/+1
| | | | | | | Fixes the build with only the ARM backend enabled. For some reason some other backend was pulling Object and this went unnoticed. llvm-svn: 212288
* Add support for inline asm symbols to IRObjectFile.Rafael Espindola2014-07-031-100/+1
| | | | | | This also enables it in llvm-nm so that it can be tested. llvm-svn: 212282
* Use a range loop. No functionality change.Rafael Espindola2014-06-281-4/+3
| | | | llvm-svn: 211986
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-6/+5
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-5/+6
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* Merge the used symbol scanning of MCObjectStreamer and RecordStreamer.Rafael Espindola2014-06-251-6/+2
| | | | | | This completes the refactoring of RecordStreamer. llvm-svn: 211727
* Move expression visitation logic up to MCStreamer.Rafael Espindola2014-06-251-27/+4
| | | | | | Remove the duplicate from MCRecordStreamer. No functionality change. llvm-svn: 211714
* Move some trivial methods up to MCStreamer.Rafael Espindola2014-06-251-35/+0
| | | | | | This saves some duplicated boilerplate in RecordStreamer and NullStreamer. llvm-svn: 211653
* Simplify the handling of .cfi_endproc.Rafael Espindola2014-06-251-3/+0
| | | | | | No functionality change. llvm-svn: 211651
OpenPOWER on IntegriCloud