It's simpler to do this at codegen time than to do ad-hoc constant
folding of machine instructions in SIFoldOperands.
Differential Revision: https://reviews.llvm.org/D88028
The VPTBlock has been modified to track the 'global' state of the
VPR, as well as the state for each block. Each object now just holds
a list of instructions that makeup the block, while static structures
hold the predicate information. This enables global access for
querying how both a VPT block and individual instructions are
predicated. These changes now allow us, again, to handle more
complicated cases where multiple instructions build a predicate
and/or where the same predicate in used in multiple blocks.
It doesn't, however, get us back to before the tracking was 'fixed'
as some extra logic will be required to properly handle VPT
instructions. Currently a VPT could be effectively predicated because
of it's inputs, but the existing logic will not detect that and so
will refuse to perform the transformation. This can be seen in
remat-vctp.ll test where we still don't perform the transform.
Differential Revision: https://reviews.llvm.org/D87681
We have an issue with `getFullSymbolName`: it assumes that the symbol passed is
always in the `.symtab`, what is wrong. We might calculate and report a wrong index currently.
I've added a test case revealing that.
This patch adds the "symbol index" argument to `getFullSymbolName` signature,
what fixes the issue.
Differential revision: https://reviews.llvm.org/D87899
Remove the domain from the instructions and create a shouldInspect
helper for LowOverheadLoops which queries it or a vpr operand.
Differential Revision: https://reviews.llvm.org/D87900
When cross compiling with clang-cl, clang splits the INCLUDE env
variable around semicolons (clang/lib/Driver/ToolChains/MSVC.cpp,
MSVCToolChain::AddClangSystemIncludeArgs) and lld splits the
LIB variable similarly (lld/COFF/Driver.cpp,
LinkerDriver::addLibSearchPaths). Therefore, the consensus for
cross compilation with clang-cl and lld-link seems to be to use
semicolons, despite path lists normally being separated by colons
on unix and EnvPathSeparator being set to that.
Therefore, handle the LIB variable similarly in Clang, when
handling lib file arguments when driving linking via Clang.
This fixes commands like "clang-cl test.c -Fetest.exe kernel32.lib" in
a cross compilation setting. Normally, most users call (lld-)link
directly, but meson happens to use this command syntax for
has_function() tests.
Reapply: Change Program.h to define procid_t as ::pid_t. When included
in lldb/unittests/Host/NativeProcessProtocolTest.cpp, it is included
after an lldb namespace containing an lldb::pid_t typedef, followed
later by a "using namespace lldb;". Previously, Program.h wasn't
included in this translation unit, but now it ends up included
transitively from Process.h.
Differential Revision: https://reviews.llvm.org/D88002
This ensures that required includes and libraries such as -lm that
were added earlier aren't overwritten.
Differential Revision: https://reviews.llvm.org/D88068
This prefered over find_package as find_dependency forwards the correct
parameters for QUIET and REQUIRED to find_package.
Differential Revision: https://reviews.llvm.org/D88069
For relative symbols, add its offset when computing relocation value.
Also, warn on unsupported absolute symbols.
Differential Revision: https://reviews.llvm.org/D87407
NPM passes just use the normal versions of these analyses instead.
Also pin any tests with -analyze to legacy PM.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D87857
Updated file paths and function signatures in section
"Adding a new type".
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D88049
Extend the handling of memory intrinsics to also include non-
target-specific intrinsics, in particular masked loads and stores.
Invent "isHandledNonTargetIntrinsic" to distinguish between intrin-
sics that should be handled natively from intrinsics that can be
passed to TTI.
Add code that handles masked loads and stores and update the
testcase to reflect the results.
Differential Revision: https://reviews.llvm.org/D87340
SimplifyCFG's options should always be overridden by command line flags,
but they mistakenly weren't in the default constructor.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D87718
Scheduling information is of little value when they may disrupt the
pipeline. This patch allows omitting the scheduling information for CSR
instructions while still setting `SchedMachineModel::CompleteModel`. For
specific cases, any scheduling information added will be used by the
scheduler.
Differential revision: https://reviews.llvm.org/D85366
In order to select the immediate forms using the imported patterns, we need to
lower them into new G_VASHR/G_VLSHR target generic ops. Add a combine to do this
matching build_vector of constant operands.
With this, we get selection for free.
This reverts commit 4d85444b317a00a3e15da63cdb693d272c99a0cc.
This commit broke building lldb's NativeProcessProtocolTest.cpp,
with errors like these:
In file included from include/llvm/Support/Process.h:32:0,
from tools/lldb/unittests/Host/NativeProcessProtocolTest.cpp:12:
include/llvm/Support/Program.h:39:11: error: reference to ‘pid_t’ is ambiguous
typedef pid_t procid_t;
/usr/include/sched.h:38:17: note: candidates are: typedef __pid_t pid_t
typedef __pid_t pid_t;
tools/lldb/include/lldb/lldb-types.h:85:18: note: typedef uint64_t lldb::pid_t
typedef uint64_t pid_t;
1. Store intrinsic ID in ParseMemoryInst instead of a boolean flag
"IsTargetMemInst". This will make it easier to add support for
target-independent intrinsics.
2. Extract the complex multiline conditions from EarlyCSE::processNode
into a new function "getMatchingValue".
Differential Revision: https://reviews.llvm.org/D87691
The patch modifies HexagonVectorLoopCarriedReuse pass to make it compatible with both Legacy Pass Manager through HexagonVectorLoopCarriedReuseLegacyPass and with New Pass Manager through HexagonVectorLoopCarriedReusePass.
Reviewed By: pzheng
Differential Revision: https://reviews.llvm.org/D86955
If we are going to write handler data (that is written as variable
length data following after the unwind info in .xdata), we need to
emit the handler data immediately, but for cases where no such
info is going to be written, skip emitting it right away. (Unwind
info for all remaining functions that hasn't gotten it emitted
directly is emitted at the end.)
This does slightly change the ordering of sections (triggering a
bunch of updates to DebugInfo/COFF tests), but the change should be
benign.
This also matches GCC's assembly output, which doesn't output
.seh_handlerdata unless it actually is needed.
For ARM64, the unwind info can be packed into the runtime function
entry itself (leaving no data in the .xdata section at all), but
that can only be done if there's no follow-on data in the .xdata
section. If emission of the unwind info is triggered via
EmitWinEHHandlerData (or the .seh_handlerdata directive), which
implicitly switches to the .xdata section, there's a chance of the
caller wanting to pass further data there, so the packed format
can't be used in that case.
Differential Revision: https://reviews.llvm.org/D87448
When cross compiling with clang-cl, clang splits the INCLUDE env
variable around semicolons (clang/lib/Driver/ToolChains/MSVC.cpp,
MSVCToolChain::AddClangSystemIncludeArgs) and lld splits the
LIB variable similarly (lld/COFF/Driver.cpp,
LinkerDriver::addLibSearchPaths). Therefore, the consensus for
cross compilation with clang-cl and lld-link seems to be to use
semicolons, despite path lists normally being separated by colons
on unix and EnvPathSeparator being set to that.
Therefore, handle the LIB variable similarly in Clang, when
handling lib file arguments when driving linking via Clang.
This fixes commands like "clang-cl test.c -Fetest.exe kernel32.lib" in
a cross compilation setting. Normally, most users call (lld-)link
directly, but meson happens to use this command syntax for
has_function() tests.
Differential Revision: https://reviews.llvm.org/D88002
This pass is like DeadCodeEliminationPass, but only does one pass
through a function instead of iterating on users of eliminated
instructions.
DeadCodeEliminationPass should be used in all cases.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D87933
