| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
llvm-svn: 226940
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The default copy and assignment operators for these objects probably don't actually do what the clients intend, so they should be deleted.
Places using the assignment operator to set the value of an option should cast to the option's data type first to call into the override for operator=. Places using the copy constructor just need to be changed to not copy (i.e. passing by const reference instead of value).
Reviewers: dexonsmith, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7114
llvm-svn: 226762
|
|
|
|
| |
llvm-svn: 223183
|
|
|
|
| |
llvm-svn: 222945
|
|
|
|
| |
llvm-svn: 218318
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates the few
remaining clients over to SectionMemoryManager.
http://llvm.org/PR20848
llvm-svn: 218316
|
|
|
|
|
|
|
|
| |
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 216982
|
|
|
|
| |
llvm-svn: 216583
|
|
|
|
|
|
|
| |
Long term the idea if for the engine to not own the buffers, but for now
this is consistent with the rest of the API.
llvm-svn: 216484
|
|
|
|
| |
llvm-svn: 216466
|
|
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|
|
|
|
| |
llvm-svn: 216071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
llvm-svn: 216002
|
|
|
|
| |
llvm-svn: 215967
|
|
|
|
| |
llvm-svn: 215566
|
|
|
|
|
|
|
|
|
|
|
| |
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 215154
|
|
|
|
|
|
|
|
|
| |
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
llvm-svn: 215111
|
|
|
|
|
|
|
|
| |
Also fix the error handling. No testcaes, issue found by inspection.
Thanks to David Blaikie for the suggestion.
llvm-svn: 214535
|
|
|
|
| |
llvm-svn: 214533
|
|
|
|
| |
llvm-svn: 214377
|
|
|
|
| |
llvm-svn: 212405
|
|
|
|
|
|
|
| |
Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.
llvm-svn: 211595
|
|
|
|
| |
llvm-svn: 210876
|
|
|
|
|
|
| |
This should make sure that most new uses use the std prefix.
llvm-svn: 210835
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This starts in MCJIT::getSymbolAddress where the
unique_ptr<object::Binary> is release()d and (after a cast) passed to a
single caller, MCJIT::addObjectFile.
addObjectFile calls RuntimeDyld::loadObject.
RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile
And the pointer is never owned at this point. I say this point, because
the alternative codepath, RuntimeDyldMachO::createObjectFile certainly
does take ownership, so this seemed like a good hint that this was a/the
right place to take ownership.
llvm-svn: 207580
|
|
|
|
| |
llvm-svn: 207176
|
|
|
|
|
|
| |
definition below all of the header #include lines, tools edition.
llvm-svn: 206848
|
|
|
|
|
|
| |
class.
llvm-svn: 203345
|
|
|
|
|
|
|
|
|
|
| |
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
|
|
|
|
| |
llvm-svn: 202957
|
|
|
|
|
|
|
|
|
| |
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
llvm-svn: 202052
|
|
|
|
|
|
|
|
|
|
| |
Eliminates the LLI_BUILDING_CHILD build hack from r199885.
Also add a FIXME to remove code that tricks the tests into passing when the
feature fails to work. Please don't do stuff like this, the tests exist for a
reason!
llvm-svn: 199929
|
|
|
|
|
|
|
| |
The execution code path crashes if it can't execute the binary so we might as
well take precautions here.
llvm-svn: 199844
|
|
|
|
| |
llvm-svn: 199835
|
|
|
|
| |
llvm-svn: 199776
|
|
|
|
| |
llvm-svn: 199275
|
|
|
|
|
|
|
|
|
|
|
|
| |
MCJIT remote execution (ChildTarget+RemoteTargetExternal) protocol was in
dire need of refactoring. It was fail-prone, had no error reporting and
implemented the same message logic on every single function.
This patch rectifies it, and makes it work on ARM, where it was randomly
failing. Other architectures shall profit from this change as well, making
their buildbots and releases more reliable.
llvm-svn: 199261
|
|
|
|
| |
llvm-svn: 198929
|
|
|
|
| |
llvm-svn: 198928
|
|
|
|
| |
llvm-svn: 198927
|
|
|
|
|
|
| |
new in C++11.
llvm-svn: 198853
|
|
|
|
|
|
|
|
|
|
|
| |
root path to which object files managed by the LLIObjectCache instance should be
written. This option defaults to "", in which case objects are cached in the
same directory as the bitcode they are derived from.
The load-object-a.ll test has been rewritten to use this option to support
testing in environments where the test directory is not writable.
llvm-svn: 198852
|
|
|
|
| |
llvm-svn: 198821
|
|
|
|
|
|
|
|
|
| |
I believe the bot failures on linux systems were due to overestimating the
alignment of object-files within archives, which are only guaranteed to be
two-byte aligned. I have reduced the alignment in
RuntimeDyldELF::createObjectImageFromFile accordingly.
llvm-svn: 198737
|
|
|
|
| |
llvm-svn: 196654
|
|
|
|
| |
llvm-svn: 196641
|
|
|
|
|
|
| |
Patch by Andy Kaylor, with minor edits to resolve merge conflicts.
llvm-svn: 196639
|
|
|
|
| |
llvm-svn: 193571
|
|
|
|
| |
llvm-svn: 193570
|
|
|
|
| |
llvm-svn: 193552
|