summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [NFC][ORC] Fix typos and whitespaces in commentsStefan Gränitz2020-01-031-1/+1
|
* [ORC][JITLink] Add support for weak references, and improve handling of staticLang Hames2019-11-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libraries. This patch substantially updates ORCv2's lookup API in order to support weak references, and to better support static archives. Key changes: -- Each symbol being looked for is now associated with a SymbolLookupFlags value. If the associated value is SymbolLookupFlags::RequiredSymbol then the symbol must be defined in one of the JITDylibs being searched (or be able to be generated in one of these JITDylibs via an attached definition generator) or the lookup will fail with an error. If the associated value is SymbolLookupFlags::WeaklyReferencedSymbol then the symbol is permitted to be undefined, in which case it will simply not appear in the resulting SymbolMap if the rest of the lookup succeeds. Since lookup now requires these flags for each symbol, the lookup method now takes an instance of a new SymbolLookupSet type rather than a SymbolNameSet. SymbolLookupSet is a vector-backed set of (name, flags) pairs. Clients are responsible for ensuring that the set property (i.e. unique elements) holds, though this is usually simple and SymbolLookupSet provides convenience methods to support this. -- Lookups now have an associated LookupKind value, which is either LookupKind::Static or LookupKind::DLSym. Definition generators can inspect the lookup kind when determining whether or not to generate new definitions. The StaticLibraryDefinitionGenerator is updated to only pull in new objects from the archive if the lookup kind is Static. This allows lookup to be re-used to emulate dlsym for JIT'd symbols without pulling in new objects from archives (which would not happen in a normal dlsym call). -- JITLink is updated to allow externals to be assigned weak linkage, and weak externals now use the SymbolLookupFlags::WeaklyReferencedSymbol value for lookups. Unresolved weak references will be assigned the default value of zero. Since this patch was modifying the lookup API anyway, it alo replaces all of the "MatchNonExported" boolean arguments with a "JITDylibLookupFlags" enum for readability. If a JITDylib's associated value is JITDylibLookupFlags::MatchExportedSymbolsOnly then the lookup will only match against exported (non-hidden) symbols in that JITDylib. If a JITDylib's associated value is JITDylibLookupFlags::MatchAllSymbols then the lookup will match against any symbol defined in the JITDylib.
* AArch64: support arm64_32, an ILP32 slice for watchOS.Tim Northover2019-09-121-1/+3
| | | | | | | | This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM. FastISel is mostly disabled for now since it would generate incorrect code for ILP32. llvm-svn: 371722
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-231-2/+3
| | | | | | | | | | | | | 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
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-9/+9
| | | | | | | | 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] Rename MaterializationResponsibility resolve and emit methods toLang Hames2019-06-131-2/+2
| | | | | | | | | | | | | 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
* [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-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [ORC] Fix hex printing of uint64_t values.Lang Hames2018-10-311-1/+1
| | | | | | | A plain "%x" format string will drop the high 32-bits. Use the PRIx64 macro instead. llvm-svn: 345696
* [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.Lang Hames2018-10-231-1/+1
| | | | llvm-svn: 345098
* Revert r345077 "[ORC] Change how non-exported symbols are matched during ↵Reid Kleckner2018-10-231-1/+1
| | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | 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] Make the VModuleKey optional, propagate it via MaterializationUnit andLang Hames2018-10-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | MaterializationResponsibility. VModuleKeys are intended to enable selective removal of modules from a JIT session, however for a wide variety of use cases selective removal is not needed and introduces unnecessary overhead. As of this commit, the default constructed VModuleKey value is reserved as a "do not track" value, and becomes the default when adding a new module to the JIT. This commit also changes the propagation of VModuleKeys. They were passed alongside the MaterializationResponsibity instance in XXLayer::emit methods, but are now propagated as part of the MaterializationResponsibility instance itself (and as part of MaterializationUnit when stored in a JITDylib). Associating VModuleKeys with MaterializationUnits in this way should allow for a thread-safe module removal mechanism in the future, even when a module is in the process of being compiled, by having the MaterializationResponsibility object check in on its VModuleKey's state before commiting its results to the JITDylib. llvm-svn: 344643
* [ORC] During lookup, do not match against hidden symbols in other JITDylibs.Lang Hames2018-10-131-1/+2
| | | | | | | | | | | | This adds two arguments to the main ExecutionSession::lookup method: MatchNonExportedInJD, and MatchNonExported. These control whether and where hidden symbols should be matched when searching a list of JITDylibs. A similar effect could have been achieved by filtering search results, but this would have involved materializing symbol definitions (since materialization is triggered on lookup) only to throw the results away, among other issues. llvm-svn: 344467
* [ORC] Promote and rename private symbols inside the CompileOnDemand layer,Lang Hames2018-10-091-1/+12
| | | | | | | | | | | | | | | rather than require them to have been promoted before being passed in. Dropping this precondition is better for layer composition (CompileOnDemandLayer was the only one that placed pre-conditions on the modules that could be added). It also means that the promoted private symbols do not show up in the target JITDylib's symbol table. Instead, they are confined to the hidden implementation dylib that contains the actual definitions. For the 403.gcc testcase this cut down the public symbol table size from ~15,000 symbols to ~4000, substantially reducing symbol dependence tracking costs. llvm-svn: 344078
* [ORC] Pass symbol name to discard by const reference.Lang Hames2018-10-061-1/+1
| | | | | | This saves some unnecessary atomic ref-counting operations. llvm-svn: 343927
* [ORC] Add an 'intern' method to ExecutionEngine for interning symbol names.Lang Hames2018-09-301-2/+2
| | | | | | | This cuts down on boilerplate by reducing 'ES.getSymbolStringPool().intern(...)' to 'ES.intern(...)'. llvm-svn: 343427
* [ORC] Improve debugging output for ORC.Lang Hames2018-09-281-2/+4
| | | | | | | | | | | | (1) Print debugging output under a session lock to avoid garbled messages when compiling on multiple threads. (2) Name MaterializationUnits, add an ostream operator for them, and so they can be easily referenced in debugging output, and have that ostream operator optionally print code/data/hidden symbols provided by that materialization unit based on command line options. llvm-svn: 343323
* [ORC] Coalesce all of ORC's symbol renaming / linkage-promotion utilities intoLang Hames2018-09-271-49/+15
| | | | | | | | | | | | 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
* [ORC] Refactor trampoline pool management out of JITCompileCallbackManager.Lang Hames2018-09-261-16/+18
| | | | | | | | | | | | | | | | | This will allow trampoline pools to be re-used for a new lazy-reexport utility that generates looks up function bodies using the standard symbol lookup process (rather than using a user provided compile function). This new utility provides the same capabilities (since MaterializationUnits already allow user supplied compile functions to be run) as JITCompileCallbackManager, but can use the new asynchronous lookup functions to avoid blocking a compile thread. This patch also updates createLocalCompileCallbackManager to return an error if a callback manager can not be created, and updates clients of that API to account for the change. Finally, the OrcCBindingsStack is updates so that if a callback manager is not available for the target platform a valid stack (without support for lazy compilation) can still be constructed. llvm-svn: 343059
* [MIPS] ORC JIT supportPetar Jovanovic2018-09-111-0/+34
| | | | | | | | | | | | This patch adds support for ORC JIT for mips/mips64 architecture. In common code $static is changed to __ORCstatic because on MIPS architecture "$" is a reserved character. Patch by Luka Ercegovcevic Differential Revision: https://reviews.llvm.org/D49665 llvm-svn: 341934
* [ORC] Rename 'finalize' to 'emit' to avoid potential confusion.Lang Hames2018-08-181-1/+1
| | | | | | | | | | | | | | | An emitted symbol has had its contents written and its memory protections applied, but it is not automatically ready to execute. Prior to ORC supporting concurrent compilation, the term "finalized" could be interpreted two different (but effectively equivalent) ways: (1) The finalized symbol's contents have been written and its memory protections applied, and (2) the symbol is ready to run. Now that ORC supports concurrent compilation, sense (1) no longer implies sense (2). We have already introduced a new term, 'ready', to capture sense (2), so rename sense (1) to 'emitted' to avoid any lingering confusion. llvm-svn: 340115
* [ORC] Rename VSO to JITDylib.Lang Hames2018-08-171-3/+3
| | | | | | | | | | | | | 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
* Fix few typos in comments (write access test commit)Stefan Granitz2018-07-121-2/+2
| | | | llvm-svn: 336887
* [ORC] Add LLJIT and LLLazyJIT, and replace OrcLazyJIT in LLI with LLLazyJIT.Lang Hames2018-06-261-2/+0
| | | | | | | | | | | | | | | | | | | 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] Fix an ambiguous make_unique call.Lang Hames2018-05-301-2/+2
| | | | llvm-svn: 333492
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-301-5/+90
| | | | | | | | | 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] Fix ORC on platforms without indirection support.Lang Hames2018-03-281-1/+5
| | | | | | | | | | Previously this crashed because a nullptr (returned by createLocalIndirectStubsManagerBuilder() on platforms without indirection support) functor was unconditionally invoked. Patch by Andres Freund. Thanks Andres! llvm-svn: 328687
* [ORC] Add case statements for AArch64 to the local stub and callback managerLang Hames2017-08-151-0/+13
| | | | | | | | creation functions. This should allow lli to lazily execute code using OrcLazyJIT on AArch64. llvm-svn: 310938
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [ORC] Clone module flags metadata into the globals module in theLang Hames2016-09-041-0/+9
| | | | | | | | CompileOnDemandLayer. Also contains a tweak to the orc-lazy jit in LLI to enable the test case. llvm-svn: 280632
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-2/+2
| | | | | | | | | | | | | | | | 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
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-2/+3
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
* [Orc] Merge some common code for creating CompileCallbackManagers andLang Hames2016-05-261-0/+49
| | | | | | IndirectStubsManagers. llvm-svn: 270874
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-2/+2
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* [Orc] Rename IndirectStubsManagerBase to IndirectStubsManager.Lang Hames2015-12-061-1/+1
| | | | | | No functional change. llvm-svn: 254885
* [Orc] Rename JITCompileCallbackManagerBase to JITCompileCallbackManager.Lang Hames2015-12-041-1/+1
| | | | | | | | | This class is turning into a useful interface, rather than an implementation detail, so I'm dropping the 'Base' suffix. No functional change. llvm-svn: 254693
* Refactor: Simplify boolean conditional return statements in ↵Alexander Kornienko2015-11-051-3/+1
| | | | | | | | | | lib/llvm/ExecutionEngine/Orc Patch by Richard Thomson! Differential revision: http://reviews.llvm.org/D9973 llvm-svn: 252212
* [Orc] Add support for emitting indirect stubs directly into the JIT target'sLang Hames2015-10-191-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
* OrcJIT: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-131-1/+1
| | | | llvm-svn: 250192
* [Orc] Teach the CompileOnDemand layer to clone aliases.Lang Hames2015-10-061-0/+14
| | | | | | | | This allows modules containing aliases to be lazily jit'd. Previously these failed with missing symbol errors because the aliases weren't cloned from the original module. llvm-svn: 249481
* [Orc] Fix a bug in the CompileOnDemand layer where stub decls were not clonedLang Hames2015-06-121-2/+0
| | | | | | | | | | | into partitions. Also, add an option to clone stub definitions (not just decls) into partitions: these definitions could be inlined in some places to avoid the overhead of calling via the stub. Found by inspection - no test case yet, although I plan to add a unit test for this once the CompileOnDemand layer refactoring settles down. llvm-svn: 239640
* [Orc] Reapply r236465 with fixes for the MSVC bots.Lang Hames2015-05-051-71/+87
| | | | llvm-svn: 236506
* [Orc] Revert r236465 - It broke the Windows bots.Lang Hames2015-05-041-87/+71
| | | | | | | Looks like the usual missing explicit move-constructor issue with MSVC. I should have a fix shortly. llvm-svn: 236472
* [Orc] Refactor the compile-on-demand layer to make module partitioning lazy,Lang Hames2015-05-041-71/+87
| | | | | | | | | | | | | | | and avoid cloning unused decls into every partition. Module partitioning showed up as a source of significant overhead when I profiled some trivial test cases. Avoiding the overhead of partitionging for uncalled functions helps to mitigate this. This change also means that it is no longer necessary to have a LazyEmittingLayer underneath the CompileOnDemand layer, since the CompileOnDemandLayer will not extract or emit function bodies until they are called. llvm-svn: 236465
* [Orc] Make the makeStub function propagate argument attributes onto the call toLang Hames2015-04-201-0/+1
| | | | | | | | | | | the function body. This is necessary for correctness when lazily compiling. Also, flesh out the Orc unit test infrastructure slightly, and add a unit test for this. llvm-svn: 235347
* [Orc] During module partitioning, rename anonymous and asm-private globals.Lang Hames2015-04-121-2/+40
| | | | | | | If they're not (re)named, these globals will fail to resolve when the partitioned modules are linked. llvm-svn: 234707
OpenPOWER on IntegriCloud