7 Commits

Author SHA1 Message Date
NAKAMURA Takumi
1aff188eca Orc/JITSymbol.h requires not "Compiler.h" but "DataTypes.h" due to uint64_t.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230214 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-23 11:12:52 +00:00
Lang Hames
8d353ae157 [Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code.
NFC.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230143 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-21 20:44:36 +00:00
Lang Hames
4dedd90c76 [Orc] Add a new JITSymbol constructor to build a symbol from an existing address.
This constructor is more efficient for symbols that have already been emitted,
since it avoids the construction/execution of a std::function.

Update the ObjectLinkingLayer to use this new constructor where possible.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229973 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-20 06:48:29 +00:00
Aaron Ballman
d898d31ebc Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229335 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-15 22:00:20 +00:00
Lang Hames
b7387a07d0 [Orc] Add missing casserts header to JITSymbol.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228675 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 07:26:19 +00:00
Lang Hames
cda59be931 [Orc] Fix the MSVC bots by using LLVM_EXPLICIT rather than explicit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228564 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-09 04:46:41 +00:00
Lang Hames
7d5ae5bc1f [Orc] Add a JITSymbol class to the Orc APIs, refactor APIs, update clients.
This patch refactors a key piece of the Orc APIs: It removes the
*::getSymbolAddress and *::lookupSymbolAddressIn methods, which returned target
addresses (uint64_ts), and replaces them with *::findSymbol and *::findSymbolIn
respectively, which return instances of the new JITSymbol type. Unlike the old
methods, calling findSymbol or findSymbolIn does not cause the symbol to be
immediately materialized when found. Instead, the symbol will be materialized
if/when the getAddress method is called on the returned JITSymbol. This allows
us to query for the existence of symbols without actually materializing them. In
the future I expect more information to be attached to the JITSymbol class, for
example whether the returned symbol is a weak or strong definition. This will
allow us to properly handle weak symbols and multiple definitions.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228557 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-09 01:20:51 +00:00