[ORC] Remove an unused typedef.

[ORC] Introduce LinkGraphLayer interface and LinkGraphLinkingLayer. (#120182)

Introduces a new layer interface, LinkGraphLayer, that can be used to
add LinkGraphs to an ExecutionSession.

This pa

[ORC] Introduce LinkGraphLayer interface and LinkGraphLinkingLayer. (#120182)

Introduces a new layer interface, LinkGraphLayer, that can be used to
add LinkGraphs to an ExecutionSession.

This patch moves most of ObjectLinkingLayer's functionality into a new
LinkGraphLinkingLayer which should (in the future) be able to be used
without linking libObject. ObjectLinkingLayer now inherits from
LinkGraphLinkingLayer and just handles conversion of object files to
LinkGraphs, which are then handed down to LinkGraphLinkingLayer to be
linked.

show more ...

[ORC] Make ObjectLinkingLayerJITLinkContext a private nested class.

This class is an implementation detail, so doesn't need a publicly accessible
name.

[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)

Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows p

[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)

Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows pointer comparisons (rather
than string comparisons) between Symbol names. This should improve the
performance and readability of code that bridges between JITLink and ORC (e.g.
ObjectLinkingLayer and ObjectLinkingLayer::Plugins).

To enable use of SymbolStringPtr a std::shared_ptr<SymbolStringPool> is added to
LinkGraph and threaded through to its construction sites in LLVM and Bolt. All
LinkGraphs that are to have symbol names compared by pointer equality must point
to the same SymbolStringPool instance, which in ORC sessions should be the pool
attached to the ExecutionSession.
---------

Co-authored-by: Lang Hames <lhames@gmail.com>

show more ...

Re-apply "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly" with fixes.

This reapplies aba6bb0820b, which was reverted in 28e2a891210 due to bot
failures. It contains fixes to silence warnings for

Re-apply "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly" with fixes.

This reapplies aba6bb0820b, which was reverted in 28e2a891210 due to bot
failures. It contains fixes to silence warnings for uncovered switches,
and for incorrect initializer-symbol handling on ELF and COFF.

show more ...

Revert "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Platforms."

This reverts commit aba6bb0820b247d4caf4b5e00810909214a58053 while I investigate bot
failures (e.g. https://lab.

Revert "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Platforms."

This reverts commit aba6bb0820b247d4caf4b5e00810909214a58053 while I investigate bot
failures (e.g. https://lab.llvm.org/buildbot/#/builders/143/builds/3848)

show more ...

[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Platforms.

SideEffectsOnly is a new jitlink::Scope value that corresponds to the
JITSymbolFlags::MaterializationSideEffectsOnly flag

[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Platforms.

SideEffectsOnly is a new jitlink::Scope value that corresponds to the
JITSymbolFlags::MaterializationSideEffectsOnly flag: Symbols with this scope
can be looked up (and form part of the initial interface of a LinkGraph) but
never actually resolve to an address (so can only be looked up with a
WeaklyReferencedSymbol lookup).

Previously ObjectLinkingLayer implicitly treated JITLink symbols as having this
scope, regardless of a Symbol's actual scope, if the
MaterializationSideEffectsOnly flag was set on the corresponding symbol in the
MaterializationResponsibility object. Using an explicit scope in JITLink for
this (1) allows JITLink plugins to identify and correctly handle
side-effects-only symbols, and (2) allows raw LinkGraphs to define
side-effects-only symbols without clients having to manually modify their
`MaterializationUnit::Interface`.

show more ...

[ORC] Remove redundant check from ObjectLinkingLayer.

Non-locally scoped symbols must have names.

[ExecutionEngine] Remove unused includes (NFC) (#116749)

Identified with misc-include-cleaner.

[ORC] Fix transfer to unknown ResourceTrackers (#114063)

When transferring resources, the destination tracker key may not be in
the internal map, invalidating iterators and value references. The ad

[ORC] Fix transfer to unknown ResourceTrackers (#114063)

When transferring resources, the destination tracker key may not be in
the internal map, invalidating iterators and value references. The added
test creates such situation and would fail before with "Finalized
allocation was not deallocated."

For good measure, fix the same pattern in RTDyldObjectLinkingLayer
which is harder to test because it "only" results in memory managers
being deleted in the wrong order.

show more ...

[ORC] Get rid of ObjectLinkingLayer::Plugin::getSyntheticSymbolDependencies.

Instead, when a MaterializationResponsibility contains an initializer symbol,
the Platform classes (MachO, COFF, ELFNix)

[ORC] Get rid of ObjectLinkingLayer::Plugin::getSyntheticSymbolDependencies.

Instead, when a MaterializationResponsibility contains an initializer symbol,
the Platform classes (MachO, COFF, ELFNix) will now add a defined symbol with
the same name to an arbitary block within the initializer sections, and then
add keep-alive edges from that symbol to all other init section blocks.
ObjectLinkingLayer is updated to automatically discard symbols where the
corresponding MaterializationResponsibility entry has the
MaterializationSideEffecstsOnly flag. This change simplifies both the
ObjectLinkingLayer::Plugin interface and the dependence tracking algorithm,
which no longer needs a special case for "synthetic"
(MaterializationSideEffectsOnly) symbols.

show more ...

[ORC] Simplify intra-graph dependence tracking in ObjectLinkingLayer.

ObjectLinkingLayer::registerDependencies used to propagate external symbol
dependencies (dependencies on symbols outside the cur

[ORC] Simplify intra-graph dependence tracking in ObjectLinkingLayer.

ObjectLinkingLayer::registerDependencies used to propagate external symbol
dependencies (dependencies on symbols outside the current graph) to all nodes.
Since ebe8733a11e, which merged addDependencies into notifyEmitted, the
notifyEmitted function will propagate intra-graph dependencies, so
registerDependencies no longer needs to do this.

This patch updates ObjectLinkingLayer::registerDependencies to just propagate
named dependencies (on both internal and external symbols) through anonymous
blocks, leaving the rest of the work to ExecutionSession::notifyEmitted.
It also choses a key symbol to use for blocks containing multiple symbols. The
result is both easier to read and faster.

show more ...

[orc] Avoid pathological propogation order (#107488)

In certain pathological object files we were getting extremely slow
linking because we were repeatedly propogating dependencies to the same
blo

[orc] Avoid pathological propogation order (#107488)

In certain pathological object files we were getting extremely slow
linking because we were repeatedly propogating dependencies to the same
blocks instead of accumulating as many changes as possible. Change the
order of iteration so that we go through every node in the worklist
before returning to any previous node, reducing the number of expensive
dependency iterations.

In practice, this took one case from 60 seconds to 2 seconds. Note: the
performance is still non-deterministic, because the block order itself
is non-deterministic.

rdar://133734391

show more ...

[ORC] Fix block dependence calculation in ObjectLinkingLayer.

This fixes a bug in ObjectLinkingLayer::computeBlockNonLocalDeps: The worklist
needs to be built *after* all immediate dependencies / de

[ORC] Fix block dependence calculation in ObjectLinkingLayer.

This fixes a bug in ObjectLinkingLayer::computeBlockNonLocalDeps: The worklist
needs to be built *after* all immediate dependencies / dependants are recorded,
rather than trying to populate it as part of the same loop. (Trying to do the
latter causes us to miss some blocks that should have been included in the
worklist).

This fixes a bug discovered by @Sahil123 on discord during work on
out-of-process execution support in the clang-repl.

No testcase yet. This *might* be testable with a unit test and a custom
JITLinkContext but I believe some aspects of the algorithm depend on memory
layout. I'll need to investigate that. Alternatively we could add llvm-jitlink
testcases that exercise concurrent linking (and should probably do that anyway).
Either option will require some investment and I don't want to hold this fix up
in the mean time.

show more ...

[ORC] Switch ObjectLinkingLayer::Plugins to shared ownership, copy pipeline.

Previously ObjectLinkingLayer held unique ownership of Plugins, and links
always used the Layer's plugin list at each ste

[ORC] Switch ObjectLinkingLayer::Plugins to shared ownership, copy pipeline.

Previously ObjectLinkingLayer held unique ownership of Plugins, and links
always used the Layer's plugin list at each step. This can cause problems if
plugins are added while links are in progress however, as the newly added
plugin may receive only some of the callbacks for links that are already
running.

In this patch each link gets its own copy of the pipeline that remains
consistent throughout the link's lifetime, and it is guaranteed that Plugin
objects (now with shared ownership) will remain valid until the link completes.

Coding my way home: 9.80469S, 139.03167W

show more ...

[ORC] Deallocate FinalizedAllocs on error paths in notifyEmitted.

If notifyEmitted encounters a failure (either because some plugin returned one,
or because the ResourceTracker was defunct) then we

[ORC] Deallocate FinalizedAllocs on error paths in notifyEmitted.

If notifyEmitted encounters a failure (either because some plugin returned one,
or because the ResourceTracker was defunct) then we need to deallocate the
FinalizedAlloc manually.

No testcase yet: This requires a concurrent setup -- we'll need to build some
infrastructure to coordinate links and deliberately injected failures in order
to reliably test this.

show more ...

[ORC] Propagate defineMaterializing failure when resource tracker is defunct.

Remove an overly aggressive cantFail: This call to defineMaterializing should
never fail with a duplicate symbols error

[ORC] Propagate defineMaterializing failure when resource tracker is defunct.

Remove an overly aggressive cantFail: This call to defineMaterializing should
never fail with a duplicate symbols error (since all new symbols shoul be
weak), but may fail if the tracker has become defunct in the mean time. In that
case we need to propagate the error.

show more ...

[ORC] Merge MaterializationResponsibility notifyEmitted and addDependencies

Removes the MaterializationResponsibility::addDependencies and
addDependenciesForAll methods, and transfers dependency re

[ORC] Merge MaterializationResponsibility notifyEmitted and addDependencies

Removes the MaterializationResponsibility::addDependencies and
addDependenciesForAll methods, and transfers dependency registration to
the notifyEmitted operation. The new dependency registration allows
dependencies to be specified for arbitrary subsets of the
MaterializationResponsibility's symbols (rather than just single symbols
or all symbols) via an array of SymbolDependenceGroups (pairs of symbol
sets and corresponding dependencies for that set).

This patch aims to both improve emission performance and simplify
dependence tracking. By eliminating some states (e.g. symbols having
registered dependencies but not yet being resolved or emitted) we make
some errors impossible by construction, and reduce the number of error
cases that we need to check. NonOwningSymbolStringPtrs are used for
dependence tracking under the session lock, which should reduce
ref-counting operations, and intra-emit dependencies are resolved
outside the session lock, which should provide better performance when
JITing concurrently (since some dependence tracking can happen in
parallel).

The Orc C API is updated to account for this change, with the
LLVMOrcMaterializationResponsibilityNotifyEmitted API being modified and
the LLVMOrcMaterializationResponsibilityAddDependencies and
LLVMOrcMaterializationResponsibilityAddDependenciesForAll operations
being removed.

show more ...

[ORC] Add absoluteSymbolsLinkGraph to expose absolute symbols to platform (#77008)

Adds a function to create a LinkGraph of absolute symbols, and a
callback in dynamic library search generators to

[ORC] Add absoluteSymbolsLinkGraph to expose absolute symbols to platform (#77008)

Adds a function to create a LinkGraph of absolute symbols, and a
callback in dynamic library search generators to enable using it to
expose its symbols to the platform/orc runtime. This allows e.g. using
__orc_rt_run_program to run a precompiled function that was found via
dlsym. Ideally we would use this in llvm-jitlink's own search generator,
but it will require more work to align with the Process/Platform
JITDylib split, so not handled here.

As part of this change we need to handle LinkGraphs that only have
absolute symbols.

show more ...

[jitlink][rtdyld][checker] Re-apply 4b17c81d5a5 with fixes.

This re-applies 4b17c81d5a5, "[jitlink/rtdydl][checker] Add TargetFlag
dependent disassembler switching support", which was reverted in
48

[jitlink][rtdyld][checker] Re-apply 4b17c81d5a5 with fixes.

This re-applies 4b17c81d5a5, "[jitlink/rtdydl][checker] Add TargetFlag
dependent disassembler switching support", which was reverted in
4871a9ca546 due to bot failures.

The patch has been updated to add missing plumbing for Subtarget Features and
a CPU string, which should fix the failing tests.

https://reviews.llvm.org/D158280

show more ...

Revert "[jitlink/rtdydl][checker] Add TargetFlag dependent disassembler switching support"

This reverts commit 4b17c81d5a5d3e0f514026c2b7f9b623d901cc04.

Caused buildbot failures:
https://lab.llvm.o

Revert "[jitlink/rtdydl][checker] Add TargetFlag dependent disassembler switching support"

This reverts commit 4b17c81d5a5d3e0f514026c2b7f9b623d901cc04.

Caused buildbot failures:
https://lab.llvm.org/buildbot/#/builders/230/builds/18341
https://lab.llvm.org/buildbot/#/builders/109/builds/73169
https://lab.llvm.org/buildbot/#/builders/67/builds/12597

show more ...

[jitlink/rtdydl][checker] Add TargetFlag dependent disassembler switching support

Some targets such as AArch32 make use of TargetFlags to indicate ISA mode. Depending
on the TargetFlag, MCDisassembl

[jitlink/rtdydl][checker] Add TargetFlag dependent disassembler switching support

Some targets such as AArch32 make use of TargetFlags to indicate ISA mode. Depending
on the TargetFlag, MCDisassembler and similar target specific objects should be
reinitialized with the correct Target Triple. Backends with similar needs can
easily extend this implementation for their usecase.

The drivers llvm-rtdyld and llvm-jitlink have their SymbolInfo's extended to take
TargetFlag into account. RuntimeDyldChecker can now create necessary TargetInfo
to reinitialize MCDisassembler and MCInstPrinter. The required triple is obtained
from the new getTripleFromTargetFlag function by checking the TargetFlag.

In addition, breaking changes for RuntimeDyld COFF Thumb tests are fixed by making
the backend emit a TargetFlag.

Reviewed By: lhames, sgraenitz

Differential Revision: https://reviews.llvm.org/D158280

show more ...

[Orc][AArch32] Polish Thumb symbol assertions in ObjectLinkingLayer

[ORC] Move most ORC APIs to ExecutorAddr, introduce ExecutorSymbolDef.

ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in

[ORC] Move most ORC APIs to ExecutorAddr, introduce ExecutorSymbolDef.

ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in this patch as a
replacement for JITEvaluatedSymbol: ExecutorSymbolDef is an (ExecutorAddr,
JITSymbolFlags) pair, where JITEvaluatedSymbol was a (JITTargetAddress,
JITSymbolFlags) pair.

A number of APIs had already migrated from JITTargetAddress to ExecutorAddr,
but many of ORC's internals were still using the older type. This patch aims
to address that.

Some public APIs are affected as well. If you need to migrate your APIs you can
use the following operations:

* ExecutorAddr::toPtr replaces jitTargetAddressToPointer and
jitTargetAddressToFunction.

* ExecutorAddr::fromPtr replace pointerToJITTargetAddress.

* ExecutorAddr(JITTargetAddress) creates an ExecutorAddr value from a
JITTargetAddress.

* ExecutorAddr::getValue() creates a JITTargetAddress value from an
ExecutorAddr.

JITTargetAddress and JITEvaluatedSymbol will remain in JITSymbol.h for now, but
the aim will be to eventually deprecate and remove these types (probably when
MCJIT and RuntimeDyld are deprecated).

show more ...

Reland "[JITLink] Initial AArch32 backend"

This first version lays the foundations for AArch32 support in JITLink. ELFLinkGraphBuilder_aarch32 processes REL-type relocations and populates LinkGraphs

Reland "[JITLink] Initial AArch32 backend"

This first version lays the foundations for AArch32 support in JITLink. ELFLinkGraphBuilder_aarch32 processes REL-type relocations and populates LinkGraphs from ELF object files for both big- and little-endian systems. The ArmCfg member controls subarchitecture-specific details throughout the linking process (i.e. it's passed to ELFJITLinker_aarch32).

Relocation types follow the ABI documentation's division into classes: Data (endian-sensitive), Arm (32-bit little-endian) and Thumb (2x 16-bit little-endian, "Thumb32" in the docs). The implementation of instruction encoding/decoding for relocation resolution is implemented symmetrically and is testable in isolation (see AArch32 category in JITLinkTests).

Callable Thumb functions are marked with a ThumbSymbol target-flag and stored in the LinkGraph with their real addresses. The thumb-bit is added back in when the owning JITDylib requests the address for such a symbol.

The StubsManager can generate (absolute) Thumb-state stubs for branch range extensions on v7+ targets. Proper GOT/PLT handling is not yet implemented.

This patch is based on the backend implementation in ez-clang and has just enough functionality to model the infrastructure and link a Thumb function `main()` that calls `printf()` to dump "Hello Arm!" on Armv7a. It was tested on Raspberry Pi with 32-bit Raspbian OS.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D144083

show more ...