summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc
Commit message (Collapse)AuthorAgeFilesLines
* [ORCv2] - New Speculate Query ImplementationPraveen Velliengiri2019-08-272-56/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces, SequenceBBQuery - new heuristic to find likely next callable functions it tries to find the blocks with calls in order of execution sequence of Blocks. It still uses BlockFrequencyAnalysis to find high frequency blocks. For a handful of hottest blocks (plan to customize), the algorithm traverse and discovered the caller blocks along the way to Entry Basic Block and Exit Basic Block. It uses Block Hint, to stop traversing the already visited blocks in both direction. It implicitly assumes that once the block is visited during discovering entry or exit nodes, revisiting them again does not add much. It also branch probability info (cached result) to traverse only hot edges (planned to customize) from hot blocks. Without BPI, the algorithm mostly return's all the blocks in the CFG with calls. It also changes the heuristic queries, so they don't maintain states. Hence it is safe to call from multiple threads. It also implements, new instrumentation to avoid jumping into JIT on every call to the function with the help _orc_speculate.decision.block and _orc_speculate.block. "Speculator Registration Mechanism is also changed" - kudos to @lhames Open to review, mostly looking to change implementation of SequeceBBQuery heuristics with good data structure choices. Reviewers: lhames, dblaikie Reviewed By: lhames Subscribers: mgorny, hiraditya, mgrang, llvm-commits, lhames Tags: #speculative_compilation_in_orc, #llvm Differential Revision: https://reviews.llvm.org/D66399 llvm-svn: 370092
* [JITLink][ORC] Track eh-frame section size for registration/deregistration.Lang Hames2019-08-271-30/+33
| | | | | | | | | | | | | | | On MachO, processing of the eh-frame section should stop if the end of the __eh_frame section is reached, regardless of whether or not there is a null CFI length field at the end of the section. This patch tracks the eh-frame section size and threads it through the appropriate APIs so that processing can be terminated correctly. No testcase yet: This patch is all API plumbing (rather than modification of linked memory) which the existing infrastructure does not provide a way of testing. Committing without a testcase until I have an idea of how to write one. llvm-svn: 370074
* [ORC] Make sure that queries on emitted-but-not-ready symbols fail correctly.Lang Hames2019-08-261-110/+81
| | | | | | | | | | | | | | | | | In r369808 the failure scheme for ORC symbols was changed to make MaterializationResponsibility objects responsible for failing the symbols they represented. This simplifies error logic in the case where symbols are still covered by a MaterializationResponsibility, but left a gap in error handling: Symbols that have been emitted but are not yet ready (due to a dependence on some unemitted symbol) are not covered by a MaterializationResponsibility object. Under the scheme introduced in r369808 such symbols would be moved to the error state, but queries on those symbols were never notified. This led to deadlocks when such symbols were failed. This commit updates error logic to immediately fail queries on any symbol that has already been emitted if one of its dependencies fails. llvm-svn: 369976
* [ORC] Fix an overly aggressive assert.Lang Hames2019-08-261-3/+6
| | | | | | | | Symbols that have not been queried will not have MaterializingInfo entries, so remove the assert that all failed symbols should have these entries. Also updates the loop to only remove entries that were found earlier. llvm-svn: 369975
* [ORC] Remove query dependencies when symbols are resolved.Lang Hames2019-08-231-0/+1
| | | | | | | | | | If the dependencies are not removed then a late failure (one symbol covered by the query failing after others have already been resolved) can result in an attempt to detach the query from already finalized symbol, resulting in an assert/crash. This patch fixes the issue by removing query dependencies in JITDylib::resolve for symbols that meet the required state. llvm-svn: 369809
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-235-100/+339
| | | | | | | | | | | | | When symbols are failed (via MaterializationResponsibility::failMaterialization) any symbols depending on them will now be moved to an error state. Attempting to resolve or emit a symbol in the error state (via the notifyResolved or notifyEmitted methods on MaterializationResponsibility) will result in an error. If notifyResolved or notifyEmitted return an error due to failure of a dependence then the caller should log or discard the error and call failMaterialization to propagate the failure to any queries waiting on the symbols being resolved/emitted (plus their dependencies). llvm-svn: 369808
* [cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFCHubert Tong2019-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL367756 (f5c40cb) increases the dependency of LLVMOrcJIT on LLVMPasses. In particular, symbols defined in LLVMPasses that are referenced by the destructor of `PassBuilder` are now referenced by LLVMOrcJIT through `Speculation.cpp.o`. We believe that referencing symbols defined in LLVMPasses in the destructor of `PassBuilder` is valid, and that adding to the set of such symbols is legitimate. To support such cases, this patch adds LLVMPasses to the set of libraries being linked when linking in LLVMOrcJIT causes such symbols from LLVMPasses to be referenced. Reviewers: Whitney, anhtuyen, pree-jackie Reviewed By: pree-jackie Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66441 llvm-svn: 369310
* [ORC] fix use-after-free detected by -Wreturn-stack-addressMatthias Gehre2019-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: llvm/lib/ExecutionEngine/Orc/Layer.cpp:53:12: warning: returning address of local temporary object [-Wreturn-stack-address] In ``` StringRef IRMaterializationUnit::getName() const { [...] return TSM.withModuleDo( [](const Module &M) { return M.getModuleIdentifier(); }); ``` `getModuleIdentifier()` returns a `const std::string &`, but the implicit return type of the lambda is `std::string` by value, and thus the returned `StringRef` refers to a temporary `std::string`. Detect by annotating `llvm::StringRef` with `[[gsl::Pointer]]`. Reviewers: lhames, sgraenitz Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66440 llvm-svn: 369306
* [ORC] Remove some stray debugging output accidentally left in r368707Lang Hames2019-08-161-2/+0
| | | | llvm-svn: 369141
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-159-28/+28
| | | | | | | | 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
* [ORC] Refactor definition-generation, add a generator for static libraries.Lang Hames2019-08-132-13/+134
| | | | | | | | | | | | | | | | | This patch replaces the JITDylib::DefinitionGenerator typedef with a class of the same name, and adds support for attaching a sequence of DefinitionGeneration objects to a JITDylib. This patch also adds a new definition generator, StaticLibraryDefinitionGenerator, that can be used to add symbols fom a static library to a JITDylib. An object from the static library will be added (via a supplied ObjectLayer reference) whenever a symbol from that object is referenced. To enable testing, lli is updated to add support for the --extra-archive option when running in -jit-kind=orc-lazy mode. llvm-svn: 368707
* Move findBBwithCalls to the file it's used in to avoid unused functionEric Christopher2019-08-131-0/+24
| | | | | | warnings. llvm-svn: 368636
* Re-land D65760/r367944 Diego Caballero2019-08-061-1/+15
| | | | | | Fixed most vexing parse ambiguation. llvm-svn: 368055
* Reverting D65760/r367944 due to buildbot failure.Puyan Lotfi2019-08-051-15/+1
| | | | | | | | http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/15952/steps/build/logs/stdio JITTargetMachineBuilder.cpp fails to build. llvm-svn: 367954
* [ORC] Add CPU name and sub-target features to detectHostDiego Caballero2019-08-051-1/+15
| | | | | | | | | This commit adds host CPU name and sub-target features to the `JITTargetMachineBuilder` created by `JITTargetMachineBuilder::detectHost()`. Differential Revision: https://reviews.llvm.org/D65760 llvm-svn: 367944
* [ORC] Work around broken GCC/libstdc++ by adding an explicit conversion.Lang Hames2019-08-051-1/+4
| | | | | | This should fix the bots that have been failing due to r367712. llvm-svn: 367921
* Speculative CompilationPraveen Velliengiri2019-08-035-6/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ORC] Remove Speculator Variants for Different Program Representations [ORC] Block Freq Analysis Speculative Compilation with Naive Block Frequency Add Applications to OrcSpeculation ORC v2 with Block Freq Query & Example Deleted BenchMark Programs Signed-off-by: preejackie <praveenvelliengiri@gmail.com> ORCv2 comments resolved [ORCV2] NFC ORCv2 NFC [ORCv2] Speculative compilation - CFGWalkQuery ORCv2 Adapting IRSpeculationLayer to new locking scheme llvm-svn: 367756
* [ORC] Remove a dead method.Lang Hames2019-08-021-7/+0
| | | | llvm-svn: 367716
* [ORC] Turn on symbol-flags overrides for LLJIT on Windows by default.Lang Hames2019-08-021-2/+8
| | | | | | | | | | | | | libObject does not apply the Exported flag to symbols in COFF object files, which can lead to assertions when the symbol flags initially derived from IR added to the JIT clash with the flags seen by the JIT linker. Both RTDyldObjectLinkingLayer and ObjectLinkingLayer have a workaround for this: they can be told to override the flags seen by the linker with the flags attached to the materialization responsibility object that was passed down to the linker. This patch modifies LLJIT's setup code to enable this override by default on platforms where COFF is the default object format. llvm-svn: 367712
* [ORC] Change the locking scheme for ThreadSafeModule.Lang Hames2019-08-026-98/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking for LLVMContexts in ORCv2. Prior to this patch contexts were locked as soon as an associated Module was emitted (to be compiled and linked), and were not unlocked until the emit call returned. This could lead to deadlocks if interdependent modules that shared contexts were compiled on different threads: when, during emission of the first module, the dependence was discovered the second module (which would provide the required symbol) could not be emitted as the thread emitting the first module still held the lock. This patch eliminates this possibility by moving to a finer-grained locking scheme. Each client holds the module lock only while they are actively operating on it. To make this finer grained locking simpler/safer to implement this patch removes the explicit lock method, 'getContextLock', from ThreadSafeModule and replaces it with a new method, 'withModuleDo', that implicitly locks the context, calls a user-supplied function object to operate on the Module, then implicitly unlocks the context before returning the result. ThreadSafeModule TSM = getModule(...); size_t NumFunctions = TSM.withModuleDo( [](Module &M) { // <- context locked before entry to lambda. return M.size(); }); Existing ORCv2 layers that operate on ThreadSafeModules are updated to use the new method. This method is used to introduce Module locking into each of the existing layers. llvm-svn: 367686
* [ORC] Suppress an ORCv1 deprecation warning.Lang Hames2019-07-181-1/+2
| | | | llvm-svn: 366485
* [ORC] Add deprecation warnings to ORCv1 layers and utilities.Lang Hames2019-07-174-27/+41
| | | | | | | | | | | | | | | | | Summary: ORCv1 is deprecated. The current aim is to remove it before the LLVM 10.0 release. This patch adds deprecation attributes to the ORCv1 layers and utilities to warn clients of the change. Reviewers: dblaikie, sgraenitz, AlexDenisov Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64609 llvm-svn: 366344
* [ORC] Add custom IR compiler configuration to LLJITBuilder to enable obj caches.Lang Hames2019-07-101-44/+35
| | | | | | | | | | LLJITBuilder now has a setCompileFunctionCreator method which can be used to construct a CompileFunction for the LLJIT instance being created. The motivating use-case for this is supporting ObjectCaches, which can now be set up at compile-function construction time. To demonstrate this an example project, LLJITWithObjectCache, is included. llvm-svn: 365671
* [JITLink][ORC] Add EHFrameRegistrar interface, use in EHFrameRegistrationPlugin.Lang Hames2019-07-041-12/+16
| | | | | | | | Replaces direct calls to eh-frame registration with calls to methods on an EHFrameRegistrar instance. This allows clients to substitute a registrar that registers frames in a remote process via IPC/RPC. llvm-svn: 365098
* [ORC] Rename MaterializationResponsibility resolve and emit methods toLang Hames2019-06-135-16/+17
| | | | | | | | | | | | | notifyResolved/notifyEmitted. The 'notify' prefix better describes what these methods do: they update the JIT symbol states and notify any pending queries that the 'resolved' and 'emitted' states have been reached (rather than actually performing the resolution or emission themselves). Since new states are going to be introduced in the near future (to track symbol registration/initialization) it's worth changing the convention pre-emptively to avoid further confusion. llvm-svn: 363322
* [ORC] Update symbol lookup to use a single callback with a required symbol stateLang Hames2019-06-078-376/+251
| | | | | | | | | | | | | | | | | | | | | | | rather than two callbacks. The asynchronous lookup API (which the synchronous lookup API wraps for convenience) used to take two callbacks: OnResolved (called once all requested symbols had an address assigned) and OnReady to be called once all requested symbols were safe to access). This patch updates the asynchronous lookup API to take a single 'OnComplete' callback and a required state (SymbolState) to determine when the callback should be made. This simplifies the common use case (where the client is interested in a specific state) and will generalize neatly as new states are introduced to track runtime initialization of symbols. Clients who were making use of both callbacks in a single query will now need to issue two queries (one for SymbolState::Resolved and another for SymbolState::Ready). Synchronous lookup API clients who were explicitly passing the WaitOnReady argument will now need neeed to pass a SymbolState instead (for 'WaitOnReady == true' use SymbolState::Ready, for 'WaitOnReady == false' use SymbolState::Resolved). Synchronous lookup API clients who were using default arugment values should see no change. llvm-svn: 362832
* [ORC] Track JIT symbol states more explicitly.Lang Hames2019-05-282-132/+105
| | | | | | | | | | | | | Prior to this patch, JITDylibs inferred symbol states (whether a symbol was newly added, materializing, resolved, or ready to run) via a combination of (1) bits in the JITSymbolFlags member, and (2) the state of some internal JITDylib data structures. This patch explicitly tracks symbol states by adding a new SymbolState member to the symbol table entries, and removing the 'Lazy' and 'Materializing' bits from JITSymbolFlags. This is a first step towards adding additional states representing initialization phases (e.g. eh-frame registration, registration with the language runtime, and static initialization). llvm-svn: 361899
* [ORC] Assert that JITDylibs have unique names.Lang Hames2019-05-211-0/+10
| | | | | | | | Patch by Praveen Velliengiri. Thanks Praveen! Differential Revision: https://reviews.llvm.org/D62139 llvm-svn: 361215
* [ORC] fix use-after-move. NFCNick Desaulniers2019-05-201-6/+4
| | | | | | | | | | | | | | | | | | | Summary: scan-build flagged a potential use-after-move in debug builds. It's not safe that a moved from value contains anything but garbage. Manually DRY up these repeated expressions. Reviewers: lhames Reviewed By: lhames Subscribers: hiraditya, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D62112 llvm-svn: 361203
* [ORC] Remove some unreachable code.Lang Hames2019-05-201-4/+1
| | | | | | Fixes http://llvm.org/PR41662. llvm-svn: 361199
* [ORC] Change handling for SymbolStringPtr tombstones and empty keys.Lang Hames2019-05-161-2/+0
| | | | | | | | | | | | | | SymbolStringPtr used to use nullptr as its empty value and (since it performed ref-count operations on any non-nullptr) a pointer to a special pool-entry instance as its tombstone. This commit changes the scheme to use two invalid pointer values as the empty and tombstone values, and broadens the ref-count guard to prevent ref-counting operations from being performed on these pointers. This should improve the performance of SymbolStringPtrs used in DenseMaps/DenseSets, as ref counting operations will no longer be performed on the tombstone. llvm-svn: 360925
* [ORC] Fix a formatting bug.Lang Hames2019-05-091-1/+1
| | | | llvm-svn: 360382
* [Support] Add error handling to sys::Process::getPageSize().Lang Hames2019-05-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the return type of sys::Process::getPageSize to Expected<unsigned> to account for the fact that the underlying syscalls used to obtain the page size may fail (see below). For clients who use the page size as an optimization only this patch adds a new method, getPageSizeEstimate, which calls through to getPageSize but discards any error returned and substitues a "reasonable" page size estimate estimate instead. All existing LLVM clients are updated to call getPageSizeEstimate rather than getPageSize. On Unix, sys::Process::getPageSize is implemented in terms of getpagesize or sysconf, depending on which macros are set. The sysconf call is documented to return -1 on failure. On Darwin getpagesize is implemented in terms of sysconf and may also fail (though the manpage documentation does not mention this). These failures have been observed in practice when highly restrictive sandbox permissions have been applied. Without this patch, the result is that getPageSize returns -1, which wreaks havoc on any subsequent code that was assuming a sane page size value. <rdar://problem/41654857> Reviewers: dblaikie, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59107 llvm-svn: 360221
* [ORC] Pass object buffer ownership back in NotifyEmitted.Lang Hames2019-05-011-19/+18
| | | | | | | | | | Clients who want to regain ownership of object buffers after they have been linked may now use the NotifyEmitted callback for this purpose. Note: Currently NotifyEmitted is only called if linking succeeds. If linking fails the buffer is always discarded. llvm-svn: 359735
* [ORC] Move SimpleCompiler/ConcurrentIRCompiler definitions into a .cpp file.Lang Hames2019-04-302-0/+87
| | | | | | | SimpleCompiler is no longer templated, so there's no reason for this code to be in a header any more. llvm-svn: 359626
* [ORC] Allow JITDylib definition generators to return Errors.Lang Hames2019-04-302-58/+94
| | | | | | | | | | | | | | | | | | | | Background: A definition generator can be attached to a JITDylib to generate new definitions in response to queries. For example: a generator that forwards calls to dlsym can map symbols from a dynamic library into the JIT process on demand. If definition generation fails then the generator should be able to return an error. This allows the JIT API to distinguish between the case where a generator does not provide a definition, and the case where it was not able to determine whether it provided a definition due to an error. The immediate motivation for this is cross-process symbol lookups: If the remote-lookup generator is attached to a JITDylib early in the search list, and if a generator failure is misinterpreted as "no definition in this JITDylib" then lookup may continue and bind to a different definition in a later JITDylib, which is a bug. llvm-svn: 359521
* [ORC] Replace the LLJIT/LLLazyJIT Create methods with Builder utilities.Lang Hames2019-04-291-105/+131
| | | | | | | | | | | LLJITBuilder and LLLazyJITBuilder construct LLJIT and LLLazyJIT instances respectively. Over time these will allow more configurable options to be added while remaining easy to use in the default case, which for default in-process JITing is now: auto J = ExitOnErr(LLJITBuilder.create()); llvm-svn: 359511
* [ORC] Add a 'plugin' interface to ObjectLinkingLayer for events/configuration.Lang Hames2019-04-261-47/+148
| | | | | | | | | | | | | ObjectLinkingLayer::Plugin provides event notifications when objects are loaded, emitted, and removed. It also provides a modifyPassConfig callback that allows plugins to modify the JITLink pass configuration. This patch moves eh-frame registration into its own plugin, and teaches llvm-jitlink to only add that plugin when performing execution runs on non-Windows platforms. This should allow us to re-enable the test case that was removed in r359198. llvm-svn: 359357
* [ORC] Remove symbols from dependency lists when failing materialization.Lang Hames2019-04-251-2/+29
| | | | | | | | | When failing materialization of a symbol X, remove X from the dependants list of any of X's dependencies. This ensures that when X's dependencies are emitted (or fail themselves) they do not try to access the no-longer-existing MaterializationInfo for X. llvm-svn: 359252
* [JITLink] Remove a lot of reduntant 'JITLink_' prefixes. NFC.Lang Hames2019-04-221-1/+1
| | | | llvm-svn: 358869
* [JITLink][ORC] Add JITLink to the list of dependencies for ORC.Lang Hames2019-04-201-1/+2
| | | | | | | | | The new ObjectLinkingLayer in ORC depends on JITLink. This should fix the build error at http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/9621 llvm-svn: 358832
* Initial implementation of JITLink - A replacement for RuntimeDyld.Lang Hames2019-04-204-62/+427
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: JITLink is a jit-linker that performs the same high-level task as RuntimeDyld: it parses relocatable object files and makes their contents runnable in a target process. JITLink aims to improve on RuntimeDyld in several ways: (1) A clear design intended to maximize code-sharing while minimizing coupling. RuntimeDyld has been developed in an ad-hoc fashion for a number of years and this had led to intermingling of code for multiple architectures (e.g. in RuntimeDyldELF::processRelocationRef) in a way that makes the code more difficult to read, reason about, extend. JITLink is designed to isolate format and architecture specific code, while still sharing generic code. (2) Support for native code models. RuntimeDyld required the use of large code models (where calls to external functions are made indirectly via registers) for many of platforms due to its restrictive model for stub generation (one "stub" per symbol). JITLink allows arbitrary mutation of the atom graph, allowing both GOT and PLT atoms to be added naturally. (3) Native support for asynchronous linking. JITLink uses asynchronous calls for symbol resolution and finalization: these callbacks are passed a continuation function that they must call to complete the linker's work. This allows for cleaner interoperation with the new concurrent ORC JIT APIs, while still being easily implementable in synchronous style if asynchrony is not needed. To maximise sharing, the design has a hierarchy of common code: (1) Generic atom-graph data structure and algorithms (e.g. dead stripping and | memory allocation) that are intended to be shared by all architectures. | + -- (2) Shared per-format code that utilizes (1), e.g. Generic MachO to | atom-graph parsing. | + -- (3) Architecture specific code that uses (1) and (2). E.g. JITLinkerMachO_x86_64, which adds x86-64 specific relocation support to (2) to build and patch up the atom graph. To support asynchronous symbol resolution and finalization, the callbacks for these operations take continuations as arguments: using JITLinkAsyncLookupContinuation = std::function<void(Expected<AsyncLookupResult> LR)>; using JITLinkAsyncLookupFunction = std::function<void(const DenseSet<StringRef> &Symbols, JITLinkAsyncLookupContinuation LookupContinuation)>; using FinalizeContinuation = std::function<void(Error)>; virtual void finalizeAsync(FinalizeContinuation OnFinalize); In addition to its headline features, JITLink also makes other improvements: - Dead stripping support: symbols that are not used (e.g. redundant ODR definitions) are discarded, and take up no memory in the target process (In contrast, RuntimeDyld supported pointer equality for weak definitions, but the redundant definitions stayed resident in memory). - Improved exception handling support. JITLink provides a much more extensive eh-frame parser than RuntimeDyld, and is able to correctly fix up many eh-frame sections that RuntimeDyld currently (silently) fails on. - More extensive validation and error handling throughout. This initial patch supports linking MachO/x86-64 only. Work on support for other architectures and formats will happen in-tree. Differential Revision: https://reviews.llvm.org/D58704 llvm-svn: 358818
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-3/+2
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-1/+2
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1923-92/+69
| | | | | | | | | | | | | | | | | 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
* Revert r351138 "[ORC] Move ORC Core symbol map and set types into their ownLang Hames2019-01-153-256/+233
| | | | | | | | header: CoreTypes.h." This commit broke some bots. Reverting while I investigate. llvm-svn: 351195
* [ORC] Move ORC Core symbol map and set types into their own header: CoreTypes.h.Lang Hames2019-01-143-233/+256
| | | | | | | This will allow other utilities (including a future RuntimeDyld replacement) to use these types without pulling in the major Core types (JITDylib, etc.). llvm-svn: 351138
* [ORC][MIPS] Fill delay-slot after `jr` instructionSimon Atanasyan2019-01-121-5/+5
| | | | | | | | | | MIPS `jr` instruction uses a delay-slot. To escape execution of arbitrary instruction we should either fill the delay-slot by `nop` instruction or swap `jr` instruction and logically preceding instruction. This fix implements the second method to generate a bit more effective code. llvm-svn: 351001
* [ORC][MIPS] Setup t9 register and call function through this registerSimon Atanasyan2019-01-121-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MIPS ABI states that every function must be called through jalr $t9. In other words, a function expect that t9 register points to the beginning of its code. A function uses this register to calculate offset to the Global Offset Table and save it to the `gp` register. ``` lui $gp, %hi(_gp_disp) addiu $gp, %lo(_gp_disp) addu $gp, $gp, $t9 ``` If `t9` and as a result `$gp` point to the wrong place the following code loads incorrect value from GOT and passes control to invalid code. ``` lw $v0,%call16(foo)($gp) jalr $t9 ``` OrcMips32 and OrcMips64 writeResolverCode methods pass control to the resolved address, but do not setup `$t9` before the call. The `t9` holds value of the beginning of `resolver` code so any attempts to call routines via GOT failed. This change fixes the problem. The `OrcLazy/hidden-visibility.ll` test starts to pass correctly. Before the change it fails on MIPS because the `exitOnLazyCallThroughFailure` called from the resolver code could not call libc routine `exit` via GOT. Differential Revision: http://reviews.llvm.org/D56058 llvm-svn: 351000
* [ORC] Rename register in the OrcMips64 resolver code comments. NFCSimon Atanasyan2018-12-231-2/+2
| | | | | | | The `fp` and `s8` register names are synonyms. But `fp` better reflects a purpose of the register. llvm-svn: 350023
OpenPOWER on IntegriCloud