[ORC] Ensure that llvm_orc_registerJITLoaderGDBAllocAction is linked into tools.

Add a reference to llvm_orc_registerJITLoaderGDBAllocAction from the
linkComponents function in the lli, llvm-jitlink

[ORC] Ensure that llvm_orc_registerJITLoaderGDBAllocAction is linked into tools.

Add a reference to llvm_orc_registerJITLoaderGDBAllocAction from the
linkComponents function in the lli, llvm-jitlink, and llvm-jitlink-executor
tools. This ensures that llvm_orc_registerJITLoaderGDBAllocAction is not
dead-stripped in optimized builds, which may cause failures in these tools.

The llvm_orc_registerJITLoaderGDBAllocAction function was originally added with
MachO debugging support in 69be352a1961a, but that patch failed to update the
linkComponents functions.

http://llvm.org/PR56817
(cherry picked from commit b5f76d83ff8b57b2a6e4897beb388837803643da)

show more ...

[llvm] Use value instead of getValue (NFC)

Remove unnecessary includes of ManagedStatic.h

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

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[ORC][ORC_RT] Integrate ORC platforms with LLJIT and lli

This change enables integrating orc::LLJIT with the ORCv2
platforms (MachOPlatform and ELFNixPlatform) and the compiler-rt orc
runtime. Chang

[ORC][ORC_RT] Integrate ORC platforms with LLJIT and lli

This change enables integrating orc::LLJIT with the ORCv2
platforms (MachOPlatform and ELFNixPlatform) and the compiler-rt orc
runtime. Changes include:

- Adding SPS wrapper functions for the orc runtime's dlfcn emulation
functions, allowing initialization and deinitialization to be invoked
by LLJIT.

- Changing the LLJIT code generation default to add UseInitArray so
that .init_array constructors are generated for ELF platforms.

- Integrating the ORCv2 Platforms into lli, and adding a
PlatformSupport implementation to the LLJIT instance used by lli which
implements initialization and deinitialization by calling the new
wrapper functions in the runtime.

Reviewed By: lhames

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

show more ...

Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options

Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options

[ORC] Return ExecutorAddrs rather than JITEvaluatedSymbols from LLJIT::lookup.

Clients don't care about linkage, and ExecutorAddr is much more ergonomic.

Revert "[NFC] Remove LinkAll*.h"

This reverts commit fe364e5dc78c58a915986d9a44cfd65f919a00c2.

Causes breakages, e.g. https://lab.llvm.org/buildbot/#/builders/188/builds/5266

[NFC] Remove LinkAll*.h

These were added to prevent functions from being removed by WPO.

But that doesn't make sense, correct WPO will not remove functions we actually use.

I noticed these because

[NFC] Remove LinkAll*.h

These were added to prevent functions from being removed by WPO.

But that doesn't make sense, correct WPO will not remove functions we actually use.

I noticed these because compiling cc1_main.cpp was pulling in random LLVM pass headers.

Reviewed By: MaskRay

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

show more ...

Support: Use sys::path::is_style_{posix,windows}() in a few places

Use the new sys::path::is_style_posix() and is_style_windows() in a few
places that need to detect the system's native path style.

Support: Use sys::path::is_style_{posix,windows}() in a few places

Use the new sys::path::is_style_posix() and is_style_windows() in a few
places that need to detect the system's native path style.

In llvm/lib/Support/Path.cpp, this patch removes most uses of the
private `real_style()`, where is_style_posix() and is_style_windows()
are just a little tidier.

Elsewhere, this removes `_WIN32` macro checks. Added a FIXME to a
FileManagerTest that seemed fishy, but maintained the existing
behaviour.

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

show more ...

[ORC] Use a Setup object for SimpleRemoteEPC construction.

SimpleRemoteEPC notionally allowed subclasses to override the
createMemoryManager and createMemoryAccess methods to use custom objects, but

[ORC] Use a Setup object for SimpleRemoteEPC construction.

SimpleRemoteEPC notionally allowed subclasses to override the
createMemoryManager and createMemoryAccess methods to use custom objects, but
could not actually be subclassed in practice (The construction process in
SimpleRemoteEPC::Create could not be re-used).

Instead of subclassing, this commit adds a SimpleRemoteEPC::Setup class that
can be used by clients to set up the memory manager and memory access members.
A default-constructed Setup object results in no change from previous behavior
(EPCGeneric* memory manager and memory access objects used by default).

show more ...

[ORC] Add TaskDispatch API and thread it through ExecutorProcessControl.

ExecutorProcessControl objects will now have a TaskDispatcher member which
should be used to dispatch work (in particular, ha

[ORC] Add TaskDispatch API and thread it through ExecutorProcessControl.

ExecutorProcessControl objects will now have a TaskDispatcher member which
should be used to dispatch work (in particular, handling incoming packets in
the implementation of remote EPC implementations like SimpleRemoteEPC).

The GenericNamedTask template can be used to wrap function objects that are
callable as 'void()' (along with an optional name to describe the task).
The makeGenericNamedTask functions can be used to create GenericNamedTask
instances without having to name the function object type.

In a future patch ExecutionSession will be updated to use the
ExecutorProcessControl's dispatcher, instead of its DispatchTaskFunction.

show more ...

[ORC] Switch from JITTargetAddress to ExecutorAddr for EPC-call APIs.

Part of the ongoing move to ExecutorAddr.

Reintroduce "[ORC] Introduce EPCGenericRTDyldMemoryManager."

This reintroduces "[ORC] Introduce EPCGenericRTDyldMemoryManager."
(bef55a2b47a938ef35cbd7b61a1e5fa74e68c9ed) and "[lli] Add ChildTarget

Reintroduce "[ORC] Introduce EPCGenericRTDyldMemoryManager."

This reintroduces "[ORC] Introduce EPCGenericRTDyldMemoryManager."
(bef55a2b47a938ef35cbd7b61a1e5fa74e68c9ed) and "[lli] Add ChildTarget dependence
on OrcTargetProcess library." (7a219d801bf2c3006482cf3cbd3170b3b4ea2e1b) which were
reverted in 99951a56842d8e4cd0706cd17a04f77b5d0f6dd0 due to bot failures.

The root cause of the bot failures should be fixed by "[ORC] Fix uninitialized
variable." (0371049277912afc201da721fa659ecef7ab7fba) and "[ORC] Wait for
handleDisconnect to complete in SimpleRemoteEPC::disconnect."
(320832cc9b7e7fea5fc8afbed75c34c4a43287ba).

show more ...

Revert "[ORC] Introduce EPCGenericRTDyldMemoryManager."

This reverts commit bef55a2b47a938ef35cbd7b61a1e5fa74e68c9ed while I investigate
failures on some bots. Also reverts "[lli] Add ChildTarget de

Revert "[ORC] Introduce EPCGenericRTDyldMemoryManager."

This reverts commit bef55a2b47a938ef35cbd7b61a1e5fa74e68c9ed while I investigate
failures on some bots. Also reverts "[lli] Add ChildTarget dependence on
OrcTargetProcess library." (7a219d801bf2c3006482cf3cbd3170b3b4ea2e1b) which was
a fallow-up to bef55a2b47a.

show more ...

[ORC] Introduce EPCGenericRTDyldMemoryManager.

EPCGenericRTDyldMemoryMnaager is an EPC-based implementation of the
RuntimeDyld::MemoryManager interface. It enables remote-JITing via EPC (backed
by a

[ORC] Introduce EPCGenericRTDyldMemoryManager.

EPCGenericRTDyldMemoryMnaager is an EPC-based implementation of the
RuntimeDyld::MemoryManager interface. It enables remote-JITing via EPC (backed
by a SimpleExecutorMemoryManager instance on the executor side) for RuntimeDyld
clients.

The lli and lli-child-target tools are updated to use SimpleRemoteEPC and
SimpleRemoteEPCServer (rather than OrcRemoteTargetClient/Server), and
EPCGenericRTDyldMemoryManager for MCJIT tests.

By enabling remote-JITing for MCJIT and RuntimeDyld-based ORC clients,
EPCGenericRTDyldMemoryManager allows us to deprecate older remote-JITing
support, including OrcTargetClient/Server, OrcRPCExecutorProcessControl, and the
Orc RPC system itself. These will be removed in future patches.

show more ...

[llvm] Replace LLVM_ATTRIBUTE_NORETURN with C++11 [[noreturn]]

[[noreturn]] can be used since Oct 2016 when the minimum compiler requirement was bumped to GCC 4.8/MSVC 2015.

Note: the definition of

[llvm] Replace LLVM_ATTRIBUTE_NORETURN with C++11 [[noreturn]]

[[noreturn]] can be used since Oct 2016 when the minimum compiler requirement was bumped to GCC 4.8/MSVC 2015.

Note: the definition of LLVM_ATTRIBUTE_NORETURN is kept for now.

show more ...

[ORC] Require ExecutorProcessControl when constructing an ExecutionSession.

Wrapper function call and dispatch handler helpers are moved to
ExecutionSession, and existing EPC-based tools are re-writ

[ORC] Require ExecutorProcessControl when constructing an ExecutionSession.

Wrapper function call and dispatch handler helpers are moved to
ExecutionSession, and existing EPC-based tools are re-written to take an
ExecutionSession argument instead.

Requiring an ExecutorProcessControl instance simplifies existing EPC based
utilities (which only need to take an ES now), and should encourage more
utilities to use the EPC interface. It also simplifies process termination,
since the session can automatically call ExecutorProcessControl::disconnect
(previously this had to be done manually, and carefully ordered with the
rest of JIT tear-down to work correctly).

show more ...

[ORC] Remove LLVM-side MachO Platform runtime support.

Support for this functionality is moving to the ORC runtime.

[ORC] Rename TargetProcessControl to ExecutorProcessControl. NFC.

This is a first step towards consistently using the term 'executor' for the
process that executes JIT'd code. I've opted for 'execut

[ORC] Rename TargetProcessControl to ExecutorProcessControl. NFC.

This is a first step towards consistently using the term 'executor' for the
process that executes JIT'd code. I've opted for 'executor' as the preferred
term over 'target' as target is already heavily overloaded ("the target
machine for the executor" is much clearer than "the target machine for the
target").

show more ...

[lli] Honor the --entry-function flag in orc and orc-lazy modes.

Fixes https://llvm.org/PR49906.

[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a C

[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.

Solution:
This patch adds two new flags

- OF_CRLF which indicates that CRLF translation is used.
- OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.

Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.

So this is the behaviour per platform with my patch:

z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode

Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return

The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
if (Flags & OF_CRLF)
CrtOpenFlags |= _O_TEXT;
```

These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp

Reviewed By: MaskRay

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

show more ...

Re-apply "[lli] Make -jit-kind=orc the default JIT engine"

MCJIT served well as the default JIT engine in lli for a long time, but the code is getting old and maintenance efforts don't seem to be in

Re-apply "[lli] Make -jit-kind=orc the default JIT engine"

MCJIT served well as the default JIT engine in lli for a long time, but the code is getting old and maintenance efforts don't seem to be in sight. In the meantime Orc became mature enough to fill that gap. The newly added greddy mode is very similar to the execution model of MCJIT. It should work as a drop-in replacement for common JIT tasks.

Reviewed By: lhames

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

show more ...