summaryrefslogtreecommitdiffstats
path: root/llvm/tools/lli
Commit message (Collapse)AuthorAgeFilesLines
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-16/+14
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-194-16/+12
| | | | | | | | | | | | | | | | | 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
* Remove TypeBuilder.h, and fix the few locations using it.James Y Knight2019-01-131-16/+10
| | | | | | | | | | | | | | This shortcut mechanism for creating types was added 10 years ago, but has seen almost no uptake since then, neither internally nor in external projects. The very small number of characters saved by using it does not seem worth the mental overhead of an additional type-creation API, so, delete it. Differential Revision: https://reviews.llvm.org/D56573 llvm-svn: 351020
* [Support] Make error banner optional in logAllUnhandledErrorsJonas Devlieghere2018-11-111-1/+1
| | | | | | | | In a lot of places an empty string was passed as the ErrorBanner to logAllUnhandledErrors. This patch makes that argument optional to simplify the call sites. llvm-svn: 346604
* [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.Lang Hames2018-10-231-7/+39
| | | | llvm-svn: 345098
* Revert r345077 "[ORC] Change how non-exported symbols are matched during ↵Reid Kleckner2018-10-231-39/+7
| | | | | | | | | | | | | | | lookup." Doesn't build on Windows. The call to 'lookup' is ambiguous. Clang and MSVC agree, anyway. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/787 C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): error C2668: 'llvm::orc::ExecutionSession::lookup': ambiguous call to overloaded function C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(823): note: could be 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(llvm::ArrayRef<llvm::orc::JITDylib *>,llvm::orc::SymbolStringPtr)' C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(817): note: or 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(const llvm::orc::JITDylibSearchList &,llvm::orc::SymbolStringPtr)' C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): note: while trying to match the argument list '(initializer list, llvm::orc::SymbolStringPtr)' llvm-svn: 345078
* [ORC] Change how non-exported symbols are matched during lookup.Lang Hames2018-10-231-7/+39
| | | | | | | | | | | | | | | | | In the new scheme the client passes a list of (JITDylib&, bool) pairs, rather than a list of JITDylibs. For each JITDylib the boolean indicates whether or not to match against non-exported symbols (true means that they should be found, false means that they should not). The MatchNonExportedInJD and MatchNonExported parameters on lookup are removed. The new scheme is more flexible, and easier to understand. This patch also updates JITDylib search orders to be lists of (JITDylib&, bool) pairs to match the new lookup scheme. Error handling is also plumbed through the LLJIT class to allow regression tests to fail predictably when a lookup from a lazy call-through fails. llvm-svn: 345077
* [ORC] Rename ORC layers to make the "new" ORC layers the default.Lang Hames2018-10-151-3/+3
| | | | | | | | | | | | | This commit adds a 'Legacy' prefix to old ORC layers and utilities, and removes the '2' suffix from the new ORC layers. If you wish to continue using the old ORC layers you will need to add a 'Legacy' prefix to your classes. If you were already using the new ORC layers you will need to drop the '2' suffix. The legacy layers will remain in-tree until the new layers reach feature parity with them. This will involve adding support for removing code from the new layers, and ensuring that performance is comperable. llvm-svn: 344572
* [ORC] Simplify naming for JITDylib definition generators.Lang Hames2018-10-151-2/+2
| | | | | | | | | Renames: JITDylib's setFallbackDefinitionGenerator method to setGenerator. DynamicLibraryFallbackGenerator class to DynamicLibrarySearchGenerator. ReexportsFallbackDefinitionGenerator to ReexportsGenerator. llvm-svn: 344489
* [ORC] Add convenience methods for creating DynamicLibraryFallbackGenerators forLang Hames2018-10-011-12/+2
| | | | | | | | libraries on disk, and for the current process. Avoids more boilerplate during JIT construction. llvm-svn: 343430
* [ORC] Add a method to JITTargetMachineBuilder to get the default data layoutLang Hames2018-10-011-6/+1
| | | | | | | | | | for the target machine. This simplifies usage during setup of concurrent JIT stacks where the client needs a DataLayout, but not a TargetMachine (TargetMachines are created on the fly by the compile threads later). llvm-svn: 343429
* [ORC] Extract and tidy up JITTargetMachineBuilder, add unit test.Lang Hames2018-09-301-2/+6
| | | | | | | | | | | (1) Adds comments for the API. (2) Removes the setArch method: This is redundant: the setArchStr method on the triple should be used instead. (3) Turns EmulatedTLS on by default. This matches EngineBuilder's behavior. llvm-svn: 343423
* [ORC] Add partitioning support to CompileOnDemandLayer2.Lang Hames2018-09-291-13/+31
| | | | | | | | | | | | | CompileOnDemandLayer2 now supports user-supplied partition functions (the original CompileOnDemandLayer already supported these). Partition functions are called with the list of requested global values (i.e. global values that currently have queries waiting on them) and have an opportunity to select extra global values to materialize at the same time. Also adds testing infrastructure for the new feature to lli. llvm-svn: 343396
* [ORC] Add more utilities to aid debugging output.Lang Hames2018-09-281-6/+11
| | | | | | | | | | | | | (1) A const accessor for the LLVMContext held by a ThreadSafeContext. (2) A const accessor for the ThreadSafeModules held by an IRMaterializationUnit. (3) A const MaterializationResponsibility reference to IRTransformLayer2's transform function. This makes IRTransformLayer2 useful for JIT debugging (since it can inspect JIT state through the responsibility argument) as well as program transformations. llvm-svn: 343365
* [ORC] Coalesce all of ORC's symbol renaming / linkage-promotion utilities intoLang Hames2018-09-271-1/+0
| | | | | | | | | | | | one SymbolLinkagePromoter utility. SymbolLinkagePromoter renames anonymous and private symbols, and bumps all linkages to at least global/hidden-visibility. Modules whose symbols have been promoted by this utility can be decomposed into sub-modules without introducing link errors. This is used by the CompileOnDemandLayer to extract single-function modules for lazy compilation. llvm-svn: 343257
* [lli] Fix ArgV setup bug when running in -jit-kind=orc-lazy mode.Lang Hames2018-09-271-1/+4
| | | | | | ArgV[ArgC] should be null. llvm-svn: 343255
* Reapply r343058 with a fix for -DLLVM_ENABLE_THREADS=OFF.Lang Hames2018-09-261-6/+48
| | | | | | | | | Modifies lit to add a 'thread_support' feature that can be used in lit test REQUIRES clauses. The thread_support flag is set if -DLLVM_ENABLE_THREADS=ON and unset if -DLLVM_ENABLE_THREADS=OFF. The lit flag is used to disable the multiple-compile-threads-basic.ll testcase when threading is disabled. llvm-svn: 343122
* Revert r343058 "[ORC] Add support for multithreaded compiles to LLJIT and ↵Hans Wennborg2018-09-261-48/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLLazyJIT." This doesn't work well in builds configured with LLVM_ENABLE_THREADS=OFF, causing the following assert when running ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll: lib/ExecutionEngine/Orc/Core.cpp:1748: Expected<llvm::JITEvaluatedSymbol> llvm::orc::lookup(const llvm::orc::JITDylibList &, llvm::orc::SymbolStringPtr): Assertion `ResultMap->size() == 1 && "Unexpected number of results"' failed. > LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads > arguments. If this is non-zero then a thread-pool will be created with the > given number of threads, and compile tasks will be dispatched to the thread > pool. > > To enable testing of this feature, two new flags are added to lli: > > (1) -compile-threads=N (N = 0 by default) controls the number of compile threads > to use. > > (2) -thread-entry can be used to execute code on additional threads. For each > -thread-entry argument supplied (multiple are allowed) a new thread will be > created and the given symbol called. These additional thread entry points are > called after static constructors are run, but before main. llvm-svn: 343099
* [ORC] Add support for multithreaded compiles to LLJIT and LLLazyJIT.Lang Hames2018-09-261-6/+48
| | | | | | | | | | | | | | | | | | | LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads arguments. If this is non-zero then a thread-pool will be created with the given number of threads, and compile tasks will be dispatched to the thread pool. To enable testing of this feature, two new flags are added to lli: (1) -compile-threads=N (N = 0 by default) controls the number of compile threads to use. (2) -thread-entry can be used to execute code on additional threads. For each -thread-entry argument supplied (multiple are allowed) a new thread will be created and the given symbol called. These additional thread entry points are called after static constructors are run, but before main. llvm-svn: 343058
* [ORC] Add ThreadSafeModule and ThreadSafeContext wrappers to support concurrentLang Hames2018-09-261-26/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compilation of IR in the JIT. ThreadSafeContext is a pair of an LLVMContext and a mutex that can be used to lock that context when it needs to be accessed from multiple threads. ThreadSafeModule is a pair of a unique_ptr<Module> and a shared_ptr<ThreadSafeContext>. This allows the lifetime of a ThreadSafeContext to be managed automatically in terms of the ThreadSafeModules that refer to it: Once all modules using a ThreadSafeContext are destructed, and providing the client has not held on to a copy of shared context pointer, the context will be automatically destructed. This scheme is necessary due to the following constraits: (1) We need multiple contexts for multithreaded compilation (at least one per compile thread plus one to store any IR not currently being compiled, though one context per module is simpler). (2) We need to free contexts that are no longer being used so that the JIT does not leak memory over time. (3) Module lifetimes are not predictable (modules are compiled as needed depending on the flow of JIT'd code) so there is no single point where contexts could be reclaimed. JIT clients not using concurrency can safely use one ThreadSafeContext for all ThreadSafeModules. JIT clients who want to be able to compile concurrently should use a different ThreadSafeContext for each module, or call setCloneToNewContextOnEmit on their top-level IRLayer. The former reduces compile latency (since no clone step is needed) at the cost of additional memory overhead for uncompiled modules (as every uncompiled module will duplicate the LLVM types, constants and metadata that have been shared). llvm-svn: 343055
* [ORC] Simplify LLJIT::Create by removing the ExecutionSession parameter.Lang Hames2018-09-101-3/+1
| | | | | | | The Create method can just construct the ExecutionSession, rather than having the client pass it in. llvm-svn: 341872
* [ORC] Add an addObjectFile method to LLJIT.Lang Hames2018-08-281-25/+38
| | | | | | | | | | The addObjectFile method adds the given object file to the JIT session, making its code available for execution. Support for the -extra-object flag is added to lli when operating in -jit-kind=orc-lazy mode to support testing of this feature. llvm-svn: 340870
* [ORC] Rename VSO to JITDylib.Lang Hames2018-08-171-2/+2
| | | | | | | | | | | | | VSO was a little close to VDSO (an acronym on Linux for Virtual Dynamic Shared Object) for comfort. It also risks giving the impression that instances of this class could be shared between ExecutionSessions, which they can not. JITDylib seems moderately less confusing, while still hinting at how this class is intended to be used, i.e. as a JIT-compiled stand-in for a dynamic library (code that would have been a dynamic library if you had wanted to compile it ahead of time). llvm-svn: 340084
* Add PerfJITEventListener for perf profiling support.Andres Freund2018-07-242-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new JIT event listener supports generating profiling data for the linux 'perf' profiling tool, allowing it to generate function and instruction level profiles. Currently this functionality is not enabled by default, but must be enabled with LLVM_USE_PERF=yes. Given that the listener has no dependencies, it might be sensible to enable by default once the initial issues have been shaken out. I followed existing precedent in registering the listener by default in lli. Should there be a decision to enable this by default on linux, that should probably be changed. Please note that until https://reviews.llvm.org/D47343 is resolved, using this functionality with mcjit rather than orcjit will not reliably work. Disregarding the previous comment, here's an example: $ cat /tmp/expensive_loop.c bool stupid_isprime(uint64_t num) { if (num == 2) return true; if (num < 1 || num % 2 == 0) return false; for(uint64_t i = 3; i < num / 2; i+= 2) { if (num % i == 0) return false; } return true; } int main(int argc, char **argv) { int numprimes = 0; for (uint64_t num = argc; num < 100000; num++) { if (stupid_isprime(num)) numprimes++; } return numprimes; } $ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o /tmp/expensive_loop.ll $ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1 $ perf inject --jit -i perf.data -o perf.jit.data $ perf report -i perf.jit.data - 92.59% lli jitted-5881-2.so [.] stupid_isprime stupid_isprime main llvm::MCJIT::runFunction llvm::ExecutionEngine::runFunctionAsMain main __libc_start_main 0x4bf6258d4c544155 + 0.85% lli ld-2.27.so [.] do_lookup_x And line-level annotations also work: │ for(uint64_t i = 3; i < num / 2; i+= 2) { │1 30: movq $0x3,-0x18(%rbp) 0.03 │1 38: mov -0x18(%rbp),%rax 0.03 │ mov -0x10(%rbp),%rcx │ shr $0x1,%rcx 3.63 │ ┌──cmp %rcx,%rax │ ├──jae 6f │ │ if (num % i == 0) 0.03 │ │ mov -0x10(%rbp),%rax │ │ xor %edx,%edx 89.00 │ │ divq -0x18(%rbp) │ │ cmp $0x0,%rdx 0.22 │ │↓ jne 5f │ │ return false; │ │ movb $0x0,-0x1(%rbp) │ │↓ jmp 73 │ │ } 3.22 │1 5f:│↓ jmp 61 │ │ for(uint64_t i = 3; i < num / 2; i+= 2) { Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D44892 llvm-svn: 337789
* [ORC] Verify modules when running LLLazyJIT in LLI, and deal with fallout.Lang Hames2018-07-021-2/+14
| | | | | | | | The verifier identified several modules that were broken due to incorrect linkage on declarations. To fix this, CompileOnDemandLayer2::extractFunction has been updated to change decls to external linkage. llvm-svn: 336150
* [ORC] Add LLJIT and LLLazyJIT, and replace OrcLazyJIT in LLI with LLLazyJIT.Lang Hames2018-06-264-410/+141
| | | | | | | | | | | | | | | | | | | LLJIT is a prefabricated ORC based JIT class that is meant to be the go-to replacement for MCJIT. Unlike OrcMCJITReplacement (which will continue to be supported) it is not API or bug-for-bug compatible, but targets the same use cases: Simple, non-lazy compilation and execution of LLVM IR. LLLazyJIT extends LLJIT with support for function-at-a-time lazy compilation, similar to what was provided by LLVM's original (now long deprecated) JIT APIs. This commit also contains some simple utility classes (CtorDtorRunner2, LocalCXXRuntimeOverrides2, JITTargetMachineBuilder) to support LLJIT and LLLazyJIT. Both of these classes are works in progress. Feedback from JIT clients is very welcome! llvm-svn: 335670
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-303-16/+7
| | | | | | | | | Previously JITCompileCallbackManager only supported single threaded code. This patch embeds a VSO (see include/llvm/ExecutionEngine/Orc/Core.h) in the callback manager. The VSO ensures that the compile callback is only executed once and that the resulting address cached for use by subsequent re-entries. llvm-svn: 333490
* [ORC] Rewrite the VSO symbol table yet again. Update related utilities.Lang Hames2018-05-161-2/+3
| | | | | | | | | | | | | | | | | | | VSOs now track dependencies for materializing symbols. Each symbol must have its dependencies registered with the VSO prior to finalization. Usually this will involve registering the dependencies returned in AsynchronousSymbolQuery::ResolutionResults for queries made while linking the symbols being materialized. Queries against symbols are notified that a symbol is ready once it and all of its transitive dependencies are finalized, allowing compilation work to be broken up and moved between threads without queries returning until their symbols fully safe to access / execute. Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are updated to support dependence tracking and more explicitly track responsibility for symbols from the point of definition until they are finalized. llvm-svn: 332541
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-2/+2
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [lli] Fix syntax error: missing ';'Jonas Devlieghere2018-04-221-2/+2
| | | | | | | Fixes build issue on the windows bots: error C2143: syntax error: missing ';' llvm-svn: 330538
* [lli] Make error handling more consistent.Jonas Devlieghere2018-04-221-15/+23
| | | | | | Makes error handling more consistent by using the helpers in support. llvm-svn: 330537
* Define InitLLVM to do common initialization all at once.Rui Ueyama2018-04-131-6/+2
| | | | | | | | | | | We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
* Rename *CommandFlags.def to *CommandFlags.incDavid Blaikie2018-04-111-1/+1
| | | | | | | | 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
* [ORC] Create a new SymbolStringPool by default in ExecutionSession constructor.Lang Hames2018-04-021-1/+2
| | | | | | This makes the common case of constructing an ExecutionSession tidier. llvm-svn: 329013
* [ORC] Re-apply r327566 with a fix for test-global-ctors.ll.Lang Hames2018-03-152-22/+21
| | | | | | Also clang-formats the patch, which I should have done the first time around. llvm-svn: 327594
* Revert "[ORC] Switch from shared_ptr to unique_ptr for addModule methods."Reid Kleckner2018-03-142-7/+7
| | | | | | | | | | | | | This reverts commit r327566, it breaks test/ExecutionEngine/OrcMCJIT/test-global-ctors.ll. The test doesn't crash with a stack trace, unfortunately. It merely returns 1 as the exit code. ASan didn't produce a report, and I reproduced this on my Linux machine and Windows box. llvm-svn: 327576
* [ORC] Switch from shared_ptr to unique_ptr for addModule methods.Lang Hames2018-03-142-7/+7
| | | | | | | Layer implementations typically mutate module state, and this is better reflected by having layers own the Module they are operating on. llvm-svn: 327566
* [ORC] Consolidate RTDyldObjectLinkingLayer GetMemMgr and GetResolver into aLang Hames2018-02-141-5/+4
| | | | | | | | | unified GetResources callback. Having a single 'GetResources' callback will simplify adding new resources in the future. llvm-svn: 325180
* [ORC] Switch to shared_ptr ownership for AsynchronousSymbolQueries.Lang Hames2018-02-141-2/+2
| | | | | | | Queries need to stay alive until each owner has set the values they are responsible for. llvm-svn: 325179
* [ORC] Remove Layer handles from the layer concept.Lang Hames2018-02-091-17/+12
| | | | | | | | | Handles were returned by addModule and used as keys for removeModule, findSymbolIn, and emitAndFinalize. Their job is now subsumed by VModuleKeys, which simplify resource management by providing a consistent handle across all layers. llvm-svn: 324700
* [ORC] Remove some unused lambda captures.Lang Hames2018-02-061-3/+3
| | | | llvm-svn: 324410
* [ORC] Start migrating ORC layers to use the new ORC Core.h APIs.Lang Hames2018-02-061-18/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular this patch switches RTDyldObjectLinkingLayer to use orc::SymbolResolver and threads the requried changse (ExecutionSession references and VModuleKeys) through the existing layer APIs. The purpose of the new resolver interface is to improve query performance and better support parallelism, both in JIT'd code and within the compiler itself. The most visibile change is switch of the <Layer>::addModule signatures from: Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod, std::shared_ptr<JITSymbolResolver> Resolver) to: Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod); Typical usage of addModule will now look like: auto K = ES.allocateVModuleKey(); Resolvers[K] = createSymbolResolver(...); Layer.addModule(K, std::move(Mod)); See the BuildingAJIT tutorial code for example usage. llvm-svn: 324405
* [ORC] Re-apply r322913 with a fix for a read-after-free error.Lang Hames2018-01-191-2/+2
| | | | | | | ExternalSymbolMap now stores the string key (rather than using a StringRef), as the object file backing the key may be removed at any time. llvm-svn: 323001
* [ORC] Revert r322913 while I investigate an ASan failure.Lang Hames2018-01-191-2/+2
| | | | llvm-svn: 322914
* [ORC] Redesign the JITSymbolResolver interface to support bulk queries.Lang Hames2018-01-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bulk queries reduce IPC/RPC overhead for cross-process JITing and expose opportunities for parallel compilation. The two new query methods are lookupFlags, which finds the flags for each of a set of symbols; and lookup, which finds the address and flags for each of a set of symbols. (See doxygen comments for more details.) The existing JITSymbolResolver class is renamed LegacyJITSymbolResolver, and modified to extend the new JITSymbolResolver class using the following scheme: - lookupFlags is implemented by calling findSymbolInLogicalDylib for each of the symbols, then returning the result of calling getFlags() on each of these symbols. (Importantly: lookupFlags does NOT call getAddress on the returned symbols, so lookupFlags will never trigger materialization, and lookupFlags will never call findSymbol, so only symbols that are part of the logical dylib will return results.) - lookup is implemented by calling findSymbolInLogicalDylib for each symbol and falling back to findSymbol if findSymbolInLogicalDylib returns a null result. Assuming a symbol is found its getAddress method is called to materialize it and the result (if getAddress succeeds) is stored in the result map, or the error (if getAddress fails) is returned immediately from lookup. If any symbol is not found then lookup returns immediately with an error. This change will break any out-of-tree derivatives of JITSymbolResolver. This can be fixed by updating those classes to derive from LegacyJITSymbolResolver instead. llvm-svn: 322913
* [lli] Make lli support -mcpu=native for CPU autodetectionCraig Topper2018-01-091-2/+2
| | | | | | | | | | | | llc, opt, and clang can all autodetect the CPU and supported features. lli cannot as far as I could tell. This patch uses the getCPUStr() and introduces a new getCPUFeatureList() and uses those in lli in place of MCPU and MAttrs. Ideally, we would merge getCPUFeatureList and getCPUFeatureStr, but opt and llc need a string and lli wanted a list. Maybe we should just return the SubtargetFeature object and let the caller decide what it needs? Differential Revision: https://reviews.llvm.org/D41833 llvm-svn: 322100
* Rename CommandFlags.h -> CommandFlags.defDavid Blaikie2017-11-271-2/+2
| | | | | | | | | 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
OpenPOWER on IntegriCloud