/Users/jiefu/llvm-project/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/OrcV2CBindingsBasicUsage.c:77:52: error: cast from 'char **' to 'const char **' must have all intermediate pointers const qualified to be safe [-Werror,-Wcast-qual]
LLVMParseCommandLineOptions(argc, (const char **)argv, "");
^
/Users/jiefu/llvm-project/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/OrcV2CBindingsAddObjectFile.c:63:52: error: cast from 'char **' to 'const char **' must have all intermediate pointers const qualified to be safe [-Werror,-Wcast-qual]
LLVMParseCommandLineOptions(argc, (const char **)argv, "");
^
/Users/jiefu/llvm-project/llvm/examples/OrcV2Examples/OrcV2CBindingsDumpObjects/OrcV2CBindingsDumpObjects.c:62:52: error: cast from 'char **' to 'const char **' must have all intermediate pointers const qualified to be safe [-Werror,-Wcast-qual]
LLVMParseCommandLineOptions(argc, (const char **)argv, "");
^
...
CYGWIN uses the same format of WIN32 for shared libraries.
As the comment says: "a shared library can't have undefined references", in this case CYGWIN must be handled like WIN32 by CMakeLists.txt, otherwise you will get several errors when linking because some symbols are undefined.
Attached patch fixes this issue and allows to complete the build process for those targets.
Differential Revision: https://reviews.llvm.org/D154794
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This reapplies 85c649bc02a, which was reverted in 35767e43d62 due to failures
with some example programs. The fix was to add export_executable_symbols to the
example programs.
This reapplies 371cb1af61d, which was reverted in 0b2240eda01 due to bot
failures.
The clang-repl test failure is fixed by dropping the process symbols definition
generator that was manually attached to the main JITDylib, since LLJIT now
exposes process symbols by default. (The bug was triggered when JIT'd code used
the process atexit provided by the generator, rather than the JIT atexit which
has been moved into the platform JITDylib).
Any LLJIT clients that see crashes in static destructors should likewise remove
any process symbol generators attached to their main JITDylib.
Configure the plugin to automatically call the debugger rendezvous breakpoint `__jit_debug_register_code()` for every translation unit (enabled) or never at all (disabled). Default API and behavior remain unchanged.
If AutoRegisterCode is turned off, it's the client's own responsibility to call the rendezvous breakpoint function at an appropriate time.
Depending on the complexity of the debugger's rendezvous breakpoint implementation, this can provide significant performance improvements in cases where many debug objects are added in sequence.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147310
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).
LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper)
that will be defined in the executable when LLVM is linked statically.
Should fix https://github.com/llvm/llvm-project/issues/61712.
DFAJumpThreading
JumpThreading
LibCallsShrink
LoopVectorize
SLPVectorizer
DeadStoreElimination
AggressiveDCE
CorrelatedValuePropagation
IndVarSimplify
These are part of the optimization pipeline, of which the legacy version is deprecated and being removed.
Try to fix flang-aarch64-sharedlibs build.
7344f8a8442a9c3cef159445f71b4f2886ed2798 introduced a use of
LLVMCreatePassBuilderOptions(), which is part of the Passes
library, while previously only InstCombine was linked.
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
There were quite a few places in the tutorial where the snippets were not up to date with the full code listings given. I have updated all of the ones I could find, which mostly involves changing `.` to `->` when accessing through a `std::unique_ptr`, changing `while (1)` to `while (true)`, and other such small changes.
There are still however a few places where I am not sure what to do, such as:
- Chapter 4: `ParseTopLevelExpr()` in chapter 3 sets the ProtoTypeAST
name to "", however it is referred to as "__anon_expr"
in chapter 4. Would it be required to mention this change
in chapter 4?
- Chapter 9: The code snippets refer to the top level expression as
"main", however the full code listing refers to it as
"__anon_expr". I think given the context of the chapter
it makes sense to refer to it as "main", so I have
updated the code listing to reflect that.
- Chapter 9: In chapter 9 the diff given for `HandleTopLevelExpression()`
deletes code that is not mentioned anywhere else, so I am
not sure what is to be done there.
- Miscellaneous: I don't think this is very important, however the
casing used for the first word of error messages
tends to vary between upper and lower case between
chapters and I do not know if it is worth reconciling
these differences.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D142323
This is part of effort in removing -enable-new-pm flag.
As a prat of this effort one of example passes SimplifyCFG must
be ported to new PM which will allow to remove the flag
calls from the tests that are using this pass.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D137103
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
In some cases it's helpful to group trackers by JITDylib. E.g. Platform classes
may want to track initializer symbols with a `JITDylib -> Tracker -> [ Symbol ]`
map. This makes it easy to collect all symbols for the JITDylib, while still
allowing efficient removal of a single tracker. Passing the JITDylib as an
argument to ResourceManager::notifyRemovingResources and
ResourceManager::notifyTransferringResources supports such use-cases.
D137915 has somehow caused a flang bot to fail: https://lab.llvm.org/buildbot/#/builders/191/builds/11279.
Given that the issue is with the legacy pipeline registration code and the legacy pipeline registration infrastructure is to be removed soon, remove this part of Bye.
Since aedeb8d5570, which switched to EPC-based eh-frame registrationin LLJIT,
the eh-frame registration functions need to be forcibly linked into the target
process.
Failure to link the eh-frame registration functions triggered a test failure in
https://green.lab.llvm.org/green/job/clang-stage1-RA/31497, which was fixed by
forcibly linking the registration functions into that test case in saf2b2214b4
(rdar://101083784), however it has also caused some tests (e.g. the C API unit
tests) that depend on successful construction of an LLJIT instance to be
skipped.
Moving the forcible registration into LLJIT.cpp fixes the general issue.
Since aedeb8d5570, which switched to EPC-based eh-frame registration, the
eh-frame registration functions need to be forcibly linked into the target
process.
We need a general solution to this problem, but for now just force it in this
example to fix the test failures in
https://green.lab.llvm.org/green/job/clang-stage1-RA/31497
rdar://101083784
After fffabd53482f34f96ab9273486538f587e3d91fc, the v2 and v3
versions produce poison instead of undef. Also adjust the v1
version, as well as the test expectations, to make the example
pass again.
Removes an unused function argument from a code listing in the Kaleidoscope turorial in step 9.
Reviewed By: dblaikie, MaskRay
Differential Revision: https://reviews.llvm.org/D128628
