Commit Graph

74 Commits

Author SHA1 Message Date
Alexander Kornienko f00654e31b Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)
Apparently, the style needs to be agreed upon first.

llvm-svn: 240390
2015-06-23 09:49:53 +00:00
Keno Fischer 73378eb1c7 [MCJIT] Add a FindGlobalVariableNamed utility
Summary: This adds FindGlobalVariableNamed to ExecutionEngine
(plus implementation in MCJIT), which is an analog of
FindFunctionNamed for GlobalVariables.

Reviewers: lhames

Reviewed By: lhames

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10421

llvm-svn: 240202
2015-06-20 00:55:58 +00:00
Alexander Kornienko 70bc5f1398 Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137
2015-06-19 15:57:42 +00:00
Benjamin Kramer bd7b1c89fc [ExecutionEngine] ArrayRefize argument passing.
No functionality change intended.

llvm-svn: 239687
2015-06-13 19:50:29 +00:00
Alexander Kornienko f817c1cb9a Use 'override/final' instead of 'virtual' for overridden methods
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' \
    -j=32 -fix -format

http://reviews.llvm.org/D8925

llvm-svn: 234679
2015-04-11 02:11:45 +00:00
Lang Hames 633fe146e9 [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.

This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.

The symbol resolution interface is modified slightly, from:

  uint64_t getSymbolAddress(const std::string &Name);

to:

  RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);

The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.


The memory management interface removes the following method:

  void notifyObjectLoaded(ExecutionEngine *EE,
                          const object::ObjectFile &) {}

as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).


The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).

The EngineBuilder class retains the existing method:

  EngineBuilder&
  setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);

and includes two new methods:

  EngineBuilder&
  setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);

  EngineBuilder&
  setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);

Clients should use EITHER:

A single call to setMCJITMemoryManager with an RTDyldMemoryManager.

OR (exclusive)

One call each to each of setMemoryManager and setSymbolResolver.

This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.

If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.

llvm-svn: 233509
2015-03-30 03:37:06 +00:00
Lang Hames 93de2a12a3 [Orc] New JIT APIs.
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
2015-01-23 21:25:00 +00:00
Lang Hames 4a5697e659 [MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.
llvm-svn: 223183
2014-12-03 00:51:19 +00:00
Lang Hames b5c7b1ff83 [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.
llvm-svn: 222840
2014-11-26 16:54:40 +00:00
Aaron Ballman 9fb411431d Reverting r222828 and r222810-r222812 as they broke the build on Windows.
http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753

llvm-svn: 222833
2014-11-26 15:27:39 +00:00
Lang Hames 829a19ae74 [MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
Previously, when loading an object file, RuntimeDyld (1) took ownership of the
ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the
object in-place, and (3) returned an ObjectImage that managed ownership of the
now-modified object and provided some convenience methods. This scheme accreted
over several years as features were tacked on to RuntimeDyld, and was both
unintuitive and unsafe (See e.g. http://llvm.org/PR20722).

This patch fixes the issue by removing all ownership and in-place modification
of object files from RuntimeDyld. Existing behavior, including debugger
registration, is preserved.

Noteworthy changes include:

(1) ObjectFile instances are now passed to RuntimeDyld by const-ref.
(2) The ObjectImage and ObjectBuffer classes have been removed entirely, they
    existed to model ownership within RuntimeDyld, and so are no longer needed.
(3) RuntimeDyld::loadObject now returns an instance of a new class,
    RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified
    object suitable for registration with the debugger, following the existing
    debugger registration scheme.
(4) The JITRegistrar class has been removed, and the GDBRegistrar class has been
    re-written as a JITEventListener.

This should fix http://llvm.org/PR20722 .

llvm-svn: 222810
2014-11-26 06:53:26 +00:00
Lang Hames 9a78334b96 [MCJIT] Start Stringref-izing the ExecutionEngine interface.
More methods to follow.

Using StringRef allows us the EE interface to work with more string types
without forcing construction of std::strings.

llvm-svn: 217794
2014-09-15 17:50:22 +00:00
Lang Hames 018452e6bc [MCJIT] Fix an iterator invalidation bug in MCJIT::finalizeObject.
The finalizeObject method calls generateCodeForModule on each of the currently
'added' objects, but generateCodeForModule moves objects out of the 'added'
set as it's called. To avoid iterator invalidation issues, the added set is
copied out before any calls to generateCodeForModule.

This should fix http://llvm.org/PR20851 .

llvm-svn: 217291
2014-09-05 23:38:35 +00:00
David Blaikie d1101574f7 unique_ptrify MCJIT::emitObject
llvm-svn: 217067
2014-09-03 19:57:35 +00:00
David Blaikie ed9709d928 unique_ptrify a bunch of stuff through RuntimeDyld::loadObject
llvm-svn: 217065
2014-09-03 19:48:09 +00:00
David Blaikie 196e323c01 unique_ptrify passing the TargetMachine to ExecutionEngine::MCJITCtor
llvm-svn: 216988
2014-09-02 22:41:07 +00:00
Eric Christopher 79cc1e3ae7 Reinstate "Nuke the old JIT."
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reinstates commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 216982
2014-09-02 22:28:02 +00:00
Rafael Espindola 7271c19420 Give ExecutionEngine of top level buffers.
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
2014-08-26 21:04:04 +00:00
Rafael Espindola 48af1c2a1a Don't own the buffer in object::Binary.
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
2014-08-19 18:44:46 +00:00
Rafael Espindola 2a8a2795ee Make it explicit that ExecutionEngine takes ownership of the modules.
llvm-svn: 215967
2014-08-19 04:04:25 +00:00
Benjamin Kramer a7c40ef022 Canonicalize header guards into a common format.
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)

Changes made by clang-tidy with minor tweaks.

llvm-svn: 215558
2014-08-13 16:26:38 +00:00
Eric Christopher b9fd9ed37e Temporarily Revert "Nuke the old JIT." as it's not quite ready to
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
2014-08-07 22:02:54 +00:00
Rafael Espindola f8b27c41e8 Nuke the old JIT.
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
2014-08-07 14:21:18 +00:00
Rafael Espindola ce47a05c7c Replace comment about ownership with std::unique_ptr.
llvm-svn: 214533
2014-08-01 18:09:32 +00:00
Rafael Espindola b9a23cdcdb Delete dead code.
llvm-svn: 214370
2014-07-31 01:14:09 +00:00
David Blaikie 7a1e775a7e PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFile
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
2014-04-29 21:52:46 +00:00
Craig Topper e73658ddbb [C++] Use 'nullptr'.
llvm-svn: 207394
2014-04-28 04:05:08 +00:00
Lang Hames 868d4b3122 Add an option to MCJIT to have it forward all sections to the
RTDyldMemoryManager, regardless of whether it thinks they're "required for
execution".

Currently, RuntimeDyld only passes sections that are "required for execution"
to the RTDyldMemoryManager, and takes "required for execution" to mean exactly
"contains symbols or relocations". There are two problems with this:
(1) It can drop sections with anonymous data that is referenced by code.
(2) It leaves the JIT client no way to inspect interesting sections that aren't
    actually required to run the program (e.g dwarf sections).

A test case is still in the works.

Future work: We may want to replace this with a generic section filtering
mechanism, but that will require more consideration. For now, this flag at least
allows clients to volunteer to do the filtering themselves.

Fixes <rdar://problem/15177691>.

llvm-svn: 204398
2014-03-20 21:06:46 +00:00
Craig Topper b51ff603ea [C++11] Add 'override' keyword to virtual methods that override their base class.
llvm-svn: 203344
2014-03-08 07:51:20 +00:00
Ahmed Charles 56440fd820 Replace OwningPtr<T> with std::unique_ptr<T>.
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
2014-03-06 05:51:42 +00:00
Lang Hames 937ec54951 Extend RTDyld API to enable optionally precomputing the total amount of memory
required for all sections in a module. This can be useful when targets or
code-models place strict requirements on how sections must be laid out
in memory.

If RTDyldMemoryManger::needsToReserveAllocationSpace() is overridden to return
true then the JIT will call the following method on the memory manager, which
can be used to preallocate the necessary memory.

void RTDyldMemoryManager::reserveAllocationSpace(uintptr_t CodeSize,
                                                 uintptr_t DataSizeRO,
                                                 uintptr_t DataSizeRW)

Patch by Vaidas Gasiunas. Thanks very much Viadas!

llvm-svn: 201259
2014-02-12 21:30:07 +00:00
Juergen Ributzka 5fe955cb75 Add target analysis passes to the codegen pipeline for MCJIT.
This patch adds the target analysis passes (usually TargetTransformInfo) to the
codgen pipeline. We also expose now the AddAnalysisPasses method through the C
API, because the optimizer passes would also benefit from better target-specific
cost models.

Reviewed by Andrew Kaylor

llvm-svn: 199926
2014-01-23 19:23:28 +00:00
Lang Hames 173c69f226 Re-apply r196639: Add support for archives and object file caching under MCJIT.
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
2014-01-08 04:09:09 +00:00
NAKAMURA Takumi 87e0880606 Whitespace cleanups.
llvm-svn: 196654
2013-12-07 11:21:42 +00:00
Lang Hames 567befd88f Revert r196639 while I investigate a bot failure.
llvm-svn: 196641
2013-12-07 04:25:19 +00:00
Lang Hames a691358078 Add support for archives and object file caching under MCJIT.
Patch by Andy Kaylor, with minor edits to resolve merge conflicts.

llvm-svn: 196639
2013-12-07 03:05:51 +00:00
Yaron Keren 1ec9df3322 Replaced non-ASCII character.
llvm-svn: 193324
2013-10-24 10:04:47 +00:00
Andrew Kaylor c89fc826b2 Optimizing MCJIT module state tracking
Patch co-developed with Yaron Keren.

llvm-svn: 193291
2013-10-24 00:19:14 +00:00
Andrew Kaylor 2fb40ce1dc FIXME comment shouldn't have been doxygen style
llvm-svn: 193131
2013-10-21 23:27:02 +00:00
Andrew Kaylor 4fba04942d Improving MCJIT/RuntimeDyld thread safety
llvm-svn: 193094
2013-10-21 17:42:06 +00:00
Yaron Keren fb95582bf1 Added comments from Andrew Kaylor.
llvm-svn: 193033
2013-10-19 09:03:20 +00:00
Andrew Kaylor c442a76c60 Adding support for deregistering EH frames with MCJIT.
Patch by Yaron Keren

llvm-svn: 192753
2013-10-16 00:14:21 +00:00
Andrew Kaylor 7bb1344c67 Adding multiple object support to MCJIT EH frame handling
llvm-svn: 192504
2013-10-11 21:25:48 +00:00
Andrew Kaylor 1b2cfb6495 Adding support and tests for multiple module handling in lli
llvm-svn: 191938
2013-10-04 00:49:38 +00:00
Filip Pizlo 7aa695e026 This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.
It's useful for the memory managers that are allocating a section to know what the name of the section is.  
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
what each allocation is for.  This allows clients that supply their own memory managers to do this.  
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
client.

This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
management C API).

llvm-svn: 191804
2013-10-02 00:59:25 +00:00
Andrew Kaylor ea395924d2 Adding multiple module support for MCJIT.
Tests to follow.

PIC with small code model and  EH frame handling will not work with multiple modules.  There are also some rough edges to be smoothed out for remote target support.

llvm-svn: 191722
2013-10-01 01:47:35 +00:00
David Tweed 2e7efedd39 Minor changes to the MCJITTest unittests to use the correct API for finalizing
the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.

llvm-svn: 182085
2013-05-17 10:01:46 +00:00
Filip Pizlo 9bc53e8467 SectionMemoryManager shouldn't be a JITMemoryManager. Previously, the
EngineBuilder interface required a JITMemoryManager even if it was being used 
to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager. 
Consequently, the SectionMemoryManager, which is meant for MCJIT, derived 
from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager 
methods that weren't relevant to the MCJIT.

This patch fixes the situation: it teaches the EngineBuilder that 
RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's 
appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if 
we're using the MCJIT. This allows us to remove the stub methods from 
SectionMemoryManager, and make SectionMemoryManager a direct subtype of 
RTDyldMemoryManager.

llvm-svn: 181820
2013-05-14 19:29:00 +00:00
Andrew Kaylor ced4e8ff6e Re-enabling MCJIT object caching with memory leak fixed
llvm-svn: 180575
2013-04-25 21:02:36 +00:00
Rafael Espindola 72780ed996 Revert "Adding object caching support to MCJIT"
This reverts commit 07f03923137a91e3cca5d7fc075a22f8c9baf33a.

Looks like it broke the valgrind bot:

http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/649

llvm-svn: 180249
2013-04-25 03:47:41 +00:00