bcm5719-llvm/llvm/examples/Kaleidoscope, branch meklort-10.0.1

[ORC] Update examples to incorporate changes in ce2207abaf9.

2020-01-29T20:50:17+00:00

This should fix the builders that were failing due to broken JIT examples after ce2207abaf9. (cherry picked from commit 98e55477558a823b1045b54d5a09681a3c0b819a)

[examples] Add missing dependency in llvm examples

2020-01-10T17:32:39+00:00

To fix build failure with BUILD_SHARED_LIBS=ON

[Kaleidoscope][BuildingAJIT] Add a missing std::move.

2019-12-15T23:37:18+00:00

This should fix the build failure described in https://github.com/llvm/llvm-project/issues/63.

[ORC] Remove the automagic Main JITDylib fram ExecutionSession.

2019-12-05T09:36:49+00:00

This patch removes the magic "main" JITDylib from ExecutionEngine. The main JITDylib was created automatically at ExecutionSession construction time, and all subsequently created JITDylibs were added to the main JITDylib's links-against list by default. This saves a couple of lines of boilerplate for simple JIT setups, but this isn't worth introducing magical behavior for. ORCv2 clients should now construct their own main JITDylib using ExecutionSession::createJITDylib and set up its linkages manually using JITDylib::setSearchOrder (or related methods in JITDylib).

Move CodeGenFileType enum to Support/CodeGen.h

2019-11-14T00:39:34+00:00

Avoids the need to include TargetMachine.h from various places just for an enum. Various other enums live here, such as the optimization level, TLS model, etc. Data suggests that this change probably doesn't matter, but it seems nice to have anyway.

Break out OrcError and RPC

2019-10-30T00:31:28+00:00

Summary: When createing an ORC remote JIT target the current library split forces the target process to link large portions of LLVM (Core, Execution Engine, JITLink, Object, MC, Passes, RuntimeDyld, Support, Target, and TransformUtils). This occurs because the ORC RPC interfaces rely on the static globals the ORC Error types require, which starts a cycle of pulling in more and more. This patch breaks the ORC RPC Error implementations out into an "OrcError" library which only depends on LLVM Support. It also pulls the ORC RPC headers into their own subdirectory. With this patch code can include the Orc/RPC/*.h headers and will only incur link dependencies on LLVMOrcError and LLVMSupport. Reviewers: lhames Reviewed By: lhames Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68732

[llvm] Migrate llvm::make_unique to std::make_unique

2019-08-15T15:54:37+00:00

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] Fix BuildingAJIT tutorial code broken by r368707.

2019-08-13T19:38:52+00:00

llvm-svn: 368740

Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFC

2019-08-05T05:43:48+00:00

F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800

[ORC] Change the locking scheme for ThreadSafeModule.

2019-08-02T15:21:37+00:00

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