summaryrefslogtreecommitdiffstats
path: root/llvm/tools/lli
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Errorize the ORC APIs.Lang Hames2017-07-072-18/+31
| | | | | | | | This patch updates the ORC layers and utilities to return and propagate llvm::Errors where appropriate. This is necessary to allow ORC to safely handle error cases in cross-process and remote JITing. llvm-svn: 307350
* [Orc] Remove the memory manager argument to addModule, and de-templatize theLang Hames2017-07-042-6/+5
| | | | | | | | | | | | | | | | symbol resolver argument. De-templatizing the symbol resolver is part of the ongoing simplification of ORC layer API. Removing the memory management argument (and delegating construction of memory managers for RTDyldObjectLinkingLayer to a functor passed in to the constructor) allows us to build JITs whose base object layers need not be compatible with RTDyldObjectLinkingLayer's memory mangement scheme. For example, a 'remote object layer' that sends fully relocatable objects directly to the remote does not need a memory management scheme at all (that will be handled by the remote). llvm-svn: 307058
* [ORC] Re-apply r306166 and r306168 with fix for regression test.Lang Hames2017-06-232-51/+53
| | | | llvm-svn: 306182
* This reverts commit r306166 and r306168.Rafael Espindola2017-06-232-53/+51
| | | | | | | | | Revert "[ORC] Remove redundant semicolons from DEFINE_SIMPLE_CONVERSION_FUNCTIONS uses." Revert "[ORC] Move ORC IR layer interface from addModuleSet to addModule and fix the module type as std::shared_ptr<Module>." They broke ExecutionEngine/OrcMCJIT/test-global-ctors.ll on linux. llvm-svn: 306176
* [ORC] Move ORC IR layer interface from addModuleSet to addModule and fix theLang Hames2017-06-232-51/+53
| | | | | | module type as std::shared_ptr<Module>. llvm-svn: 306166
* [ORC] Switch the object layer API from addObjectSet to addObject (singular), andLang Hames2017-06-221-3/+4
| | | | | | | | | move the ObjectCache from the IRCompileLayer to SimpleCompiler. This is the first in a series of patches aimed at cleaning up and improving the robustness and performance of the ORC APIs. llvm-svn: 306058
* [ExecutionEngine] Fix some Clang-tidy modernize-use-using and Include What ↵Eugene Zelenko2017-06-192-50/+66
| | | | | | You Use warnings; other minor fixes (NFC). llvm-svn: 305760
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-2/+1
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-111-1/+2
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-111-2/+1
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-061-1/+2
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
* Turn some C-style vararg into variadic templatesMehdi Amini2017-04-061-2/+1
| | | | | | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299699
* [Orc] Rename ObjectLinkingLayer -> RTDyldObjectLinkingLayer.Lang Hames2017-02-201-2/+2
| | | | | | | | | | The current ObjectLinkingLayer (now RTDyldObjectLinkingLayer) links objects in-process using MCJIT's RuntimeDyld class. In the near future I hope to add new object linking layers (e.g. a remote linking layer that links objects in the JIT target process, rather than the client), so I'm renaming this class to be more descriptive. llvm-svn: 295636
* Prune unused libdeps.NAKAMURA Takumi2016-12-081-1/+0
| | | | llvm-svn: 289060
* Fix spelling mistakes in Tools/Tests comments. NFC.Simon Pilgrim2016-11-201-1/+1
| | | | | | Identified by Pedro Giffuni in PR27636. llvm-svn: 287489
* [CMake] lli-child-target depends on intrinsics genChris Bieneman2016-11-191-0/+3
| | | | | | Messed up in r287420, it isn't just lli, but also but lli-child-target that need to depend on intrinsics_gen. llvm-svn: 287421
* [CMake] lli depends on intrinsics_genChris Bieneman2016-11-191-0/+3
| | | | | | | | | | | | | | | | ChildTarget.cpp has the following include chain: llvm/ExecutionEngine/Orc/OrcABISupport.h llvm/ExecutionEngine/Orc/IndirectionUtils.h llvm/IR/IRBuilder.h llvm/IR/ConstantFolder.h llvm/IR/InstrTypes.h llvm/IR/Attributes.h llvm/IR/Attributes.gen This means lli needs to depend on intrinsics_gen. llvm-svn: 287420
* [lli] Prefer `exit(1)` to `return 1` for consistency.Davide Italiano2016-11-171-1/+1
| | | | llvm-svn: 287277
* [lli] Factor out error handling. NFCI.Davide Italiano2016-11-171-18/+15
| | | | llvm-svn: 287276
* [ORC] Re-apply 286620 with fixes for the ErrorSuccess class.Lang Hames2016-11-113-29/+19
| | | | llvm-svn: 286639
* [ORC] Revert r286620 while I investigate a bot failure.Lang Hames2016-11-113-19/+29
| | | | llvm-svn: 286621
* [ORC] Refactor the ORC RPC utilities to add some new features.Lang Hames2016-11-113-29/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) Add support for function key negotiation. The previous version of the RPC required both sides to maintain the same enumeration for functions in the API. This means that any version skew between the client and server would result in communication failure. With this version of the patch functions (and serializable types) are defined with string names, and the derived function signature strings are used to negotiate the actual function keys (which are used for efficient call serialization). This allows clients to connect to any server that supports a superset of the API (based on the function signatures it supports). (2) Add a callAsync primitive. The callAsync primitive can be used to install a return value handler that will run as soon as the RPC function's return value is sent back from the remote. (3) Launch policies for RPC function handlers. The new addHandler method, which installs handlers for RPC functions, takes two arguments: (1) the handler itself, and (2) an optional "launch policy". When the RPC function is called, the launch policy (if present) is invoked to actually launch the handler. This allows the handler to be spawned on a background thread, or added to a work list. If no launch policy is used, the handler is run on the server thread itself. This should only be used for short-running handlers, or entirely synchronous RPC APIs. (4) Zero cost cross type serialization. You can now define serialization from any type to a different "wire" type. For example, this allows you to call an RPC function that's defined to take a std::string while passing a StringRef argument. If a serializer from StringRef to std::string has been defined for the channel type this will be used to serialize the argument without having to construct a std::string instance. This allows buffer reference types to be used as arguments to RPC calls without requiring a copy of the buffer to be made. llvm-svn: 286620
* Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson2016-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* [tools] Unbreak the GCC build (workaround a GCC bug).Davide Italiano2016-11-091-1/+2
| | | | | | | | | ../tools/llvm-extract/llvm-extract.cpp: In function ‘int main(int, char**)’: warning: ISO C++ forbids zero-size array ‘argv’ [-Wpedantic] GCC reference bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259 llvm-svn: 286396
* Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne2016-11-091-5/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: beanz, lattner, jlebar Subscribers: jholewinski, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D26235 llvm-svn: 285832
* [lli] Don't strip away const qualifier. Unbreak the gcc6 build.Davide Italiano2016-10-311-2/+2
| | | | llvm-svn: 285592
* [lli] Pass command line arguments in to the orc-lazy JIT.Lang Hames2016-10-283-6/+13
| | | | | | | This brings the LLI orc-lazy JIT's behavior more closely in-line with LLI's mcjit bahavior. llvm-svn: 285413
* Turn cl::values() (for enum) from a vararg function to using C++ variadic ↵Mehdi Amini2016-10-082-10/+5
| | | | | | | | | | | | | | | template The core of the change is supposed to be NFC, however it also fixes what I believe was an undefined behavior when calling: va_start(ValueArgs, Desc); with Desc being a StringRef. Differential Revision: https://reviews.llvm.org/D25342 llvm-svn: 283671
* [ORC] Rename RPCChannel to RPCByteChannel. NFC.Lang Hames2016-09-112-3/+4
| | | | llvm-svn: 281171
* [ORC] Clone module flags metadata into the globals module in theLang Hames2016-09-041-6/+6
| | | | | | | | CompileOnDemandLayer. Also contains a tweak to the orc-lazy jit in LLI to enable the test case. llvm-svn: 280632
* [Orc] Simplify LogicalDylib and move it back inside CompileOnDemandLayer. AlsoLang Hames2016-08-291-7/+21
| | | | | | | | | | | | | | | | | | | | switch to using one indirect stub manager per logical dylib rather than one per input module. LogicalDylib is a helper class used by the CompileOnDemandLayer to manage symbol resolution between modules during lazy compilation. In particular, it ensures that internal symbols resolve correctly even in the case where multiple input modules contain the same internal symbol name (which must to be promoted to external hidden linkage so that functions in any given module can be split out by lazy compilation). LogicalDylib's resolution scheme (before this commit) required one stub-manager per input module. This made recompilation of functions (by adding a module containing a new definition) difficult, as the stub manager for any given symbol was bound to the module that supplied the original definition. By using one stubs manager for the whole logical dylib symbols can be more easily replaced, although support for doing this is not included in this patch (it will be implemented in a follow up). llvm-svn: 279952
* [ORC] Re-apply r277896, removing bogus triples and datalayouts that broke testsLang Hames2016-08-062-22/+18
| | | | | | on linux last time. llvm-svn: 277942
* Revert r277896.Nico Weber2016-08-062-18/+22
| | | | | | | | | | | | | | | | It breaks ExecutionEngine/OrcLazy/weak-function.ll on most bots. Script: -- ... -- Exit Code: 1 Command Output (stderr): -- Could not find main function. llvm-svn: 277907
* [ORC] Add (partial) weak symbol support to the CompileOnDemand layer.Lang Hames2016-08-062-22/+18
| | | | | | | | | | | | | | This adds partial support for weak functions to the CompileOnDemandLayer by modifying the addLogicalModule method to check for existing stub definitions before building a new stub for a weak function. This scheme is sufficient to support ODR definitions, but fails for general weak definitions if strong definition is encountered after the first weak definition. (A more extensive refactor will be required to fully support weak symbols). This patch does *not* add weak symbol support to RuntimeDyld: I hope to add that in the near future. llvm-svn: 277896
* [lli] Add the ability for OrcLazyJIT to accept multiple input modules.Lang Hames2016-08-023-6/+19
| | | | | | | | | | | LLI already supported passing multiple input modules to MCJIT via the -extra-module option. This patch adds the plumbing to pass these modules to the OrcLazy JIT too. This functionality will be used in an upcoming test case for weak symbol handling. llvm-svn: 277521
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-014-15/+15
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* [cmake] Change lli-child-target to use add_llvm_utility instead of ↵Michael Gottesman2016-07-102-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | add_llvm_executable. We are currently using add_llvm_utility for executable targets that: 1. Are built by default. 2. Used for testing. 3. Are not installed by default. Originally, lli-child-target used add_llvm_tool instead of add_llvm_executable directly. This was changed so that lli-child-target would not be installed. This was good since this is only used for testing and should never be installed for users. This also had the unfortunate side effect that one can never turn off the building of lli-child-target by default, a regression for projects that by default do not want to compile any LLVM tools beyond tablegen/llvm-config. This patch changes lli-child-target to use add_llvm_utility. This makes sense since: 1. lli-child-target matches the semantics of executables created with add_llvm_utility. 2. We fix the regression since now one can use the flag LLVM_BUILD_UTILS to eliminate default compilation. llvm-svn: 275008
* Change Archive::create() from ErrorOr<...> to Expected<...> and updateKevin Enderby2016-06-291-3/+7
| | | | | | | | | its clients. This commit will break the next lld builds. I’ll be committing the matching change for lld next. llvm-svn: 274160
* Search for llvm-symbolizer binary in the same directory as argv[0], beforeRichard Smith2016-06-091-1/+1
| | | | | | | looking for it along $PATH. This allows installs of LLVM tools outside of $PATH to find the symbolizer and produce pretty backtraces if they crash. llvm-svn: 272232
* Avoid copies of std::strings and APInt/APFloats where we only read from itBenjamin Kramer2016-06-081-2/+2
| | | | | | | | As suggested by clang-tidy's performance-unnecessary-copy-initialization. This can easily hit lifetime issues, so I audited every change and ran the tests under asan, which came back clean. llvm-svn: 272126
* [Orc] Add conversion to/from RuntimeDyld::SymbolInfo for JITSymbol.Lang Hames2016-05-311-2/+1
| | | | | | | | | | This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo instances from JITSymbols. It will save more mess in the future when JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather than just a TargetAddress, since we'll be able to embed the error checking in the conversion. llvm-svn: 271350
* [Orc] Merge some common code for creating CompileCallbackManagers andLang Hames2016-05-262-55/+3
| | | | | | IndirectStubsManagers. llvm-svn: 270874
* [RuntimeDyld] Call the SymbolResolver::findSymbolInLogicalDylib method whenLang Hames2016-05-252-3/+3
| | | | | | | | | | | | | | | | | searching for external symbols, and fall back to the SymbolResolver::findSymbol method if the former returns null. This makes RuntimeDyld behave more like a static linker: Symbol definitions from within the current module's "logical dylib" will be preferred to external definitions. We can build on this behavior in the future to properly support weak symbol handling. Custom symbol resolvers that override the findSymbolInLogicalDylib method may notice changes due to this patch. Clients who have not overridden this method should generally be unaffected, however users of the OrcMCJITReplacement class may notice changes. llvm-svn: 270716
* Delete Reloc::Default.Rafael Espindola2016-05-181-15/+11
| | | | | | | | | | | | 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
* [Orc] Fix missing rename from r268845.Lang Hames2016-05-071-1/+1
| | | | llvm-svn: 268846
* [Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support.Lang Hames2016-05-072-9/+22
| | | | | | | | This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
* [lli] Fix a sign-compare warning.Lang Hames2016-04-261-2/+2
| | | | llvm-svn: 267512
* [ORC] Thread Error/Expected through the RPC library.Lang Hames2016-04-253-41/+51
| | | | | | | | | | This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
OpenPOWER on IntegriCloud