De-constify pointers to Type since they can't be modified. NFC

This was already done in most places a while ago. This just fixes the ones that crept in over time.

llvm-svn: 243842

[MCJIT] Fix PR20656 by teaching MCJIT to honor ExecutionEngine's global mapping.

This is important for users of the C API who can't supply custom symbol
resolvers yet.

llvm-svn: 243589

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

Th

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

The ExecutionEngine will act as an exception and will be unsafe to
be reused across context. We don't enforce this rule but undefined
behavior can occurs if the user tries to do it.

Reviewers: lhames

Subscribers: echristo, llvm-commits, rafael, yaron.keren

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 242414

show more ...

Revert "Make ExecutionEngine owning a DataLayout"

Reverting to fix buildbot breakage.

This reverts commit r242387.

llvm-svn: 242394

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

Th

Make ExecutionEngine owning a DataLayout

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

The ExecutionEngine will act as an exception and will be unsafe to
be reused across context. We don't enforce this rule but undefined
behavior can occurs if the user tries to do it.

Reviewers: lhames

Subscribers: echristo, llvm-commits, rafael, yaron.keren

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 242387

show more ...

Simplify the Mangler interface now that DataLayout is mandatory.

We only need to pass in a DataLayout when mangling a raw string, not when
constructing the mangler.

llvm-svn: 240405

[MCJIT] Add a FindGlobalVariableNamed utility

Summary: This adds FindGlobalVariableNamed to ExecutionEngine
(plus implementation in MCJIT), which is an analog of
FindFunctionNamed for GlobalVariable

[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

show more ...

[ExecutionEngine] ArrayRefize argument passing.

No functionality change intended.

llvm-svn: 239687

Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types

If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of charact

Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types

If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.


Call sites were found with the ASTMatcher + some semi-automated cleanup.

memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))

No functional change intended.

llvm-svn: 238602

show more ...

[ExecutionEngine] Fix MCJIT::addGlobalMapping.

This patch fixes MCJIT::addGlobalMapping by changing the implementation of the
ExecutionEngineState class. The new implementation maintains a bidirecti

[ExecutionEngine] Fix MCJIT::addGlobalMapping.

This patch fixes MCJIT::addGlobalMapping by changing the implementation of the
ExecutionEngineState class. The new implementation maintains a bidirectional
mapping between symbol names (std::strings) and addresses (uint64_ts), rather
than a mapping between Value*s and void*s.

This has fix has been made for backwards compatibility, however the strongly
preferred way to resolve unknown symbols is by writing a custom
RuntimeDyld::SymbolResolver (formerly RTDyldMemoryManager) and overriding the
findSymbol method. The addGlobalMapping method is a hangover from the legacy JIT
(which has was removed in 3.6), and may be deprecated in a future release as
part of a clean-up of the ExecutionEngine interface.

Patch by Murat Bolat. Thanks Murat!

llvm-svn: 233747

show more ...

[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.

This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol r

[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

show more ...

Fold init() helpers into constructors. NFC.

llvm-svn: 231486

Add missing includes. make_unique proliferated everywhere.

llvm-svn: 230909

[ExecutionEngine] FindFunctionNamed: Skip declarations

Summary:
Basically all other methods that look up functions by name skip them if they are mere declarations.
Do the same in FindFunctionNamed.

[ExecutionEngine] FindFunctionNamed: Skip declarations

Summary:
Basically all other methods that look up functions by name skip them if they are mere declarations.
Do the same in FindFunctionNamed.

Reviewers: lhames

Reviewed By: lhames

Subscribers: llvm-commits

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

llvm-svn: 227227

show more ...

[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 contribut

[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

show more ...

[MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.

llvm-svn: 223183

[MCJIT] Replace JITEventListener::anchor (temporarily removed in r222861), and
move GDBRegistrationListener into ExecutionEngine to avoid layering violation.

llvm-svn: 222864

[MCJIT] Remove JITEventListener's anchor until I can determine the right place
to put it. This should unbreak the Mips bots.

llvm-svn: 222861

[MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.

llvm-svn: 222840

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

[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 MemoryB

[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

show more ...

IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignment

No functional change intended, just cleaning up some code.

llvm-svn: 220187

[MCJIT] Remove a few more references to JITMemoryManager that survived r218316.

llvm-svn: 218318

[MCJIT] Delete the JTIMemoryManager and associated APIs.

This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates th

[MCJIT] Delete the JTIMemoryManager and associated APIs.

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

show more ...

unique_ptrify passing the TargetMachine to ExecutionEngine::MCJITCtor

llvm-svn: 216988