Since now we are able to handle both fixed length & variable
length instructions.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D123451
To support variable length instructions, I think of them as fixed length instructions with the "maximum length". For example, if there're three instructions with 2, 6 and 9 bytes, we can fit them into the algorithm by treating them all as 9 bytes.
Also, since we can't know the length of the instruction in advance, there is a function object with type `void(APInt &, uint64_t)` added in the parameter list of `decodeInstruction` and `fieldFromInstruction`. We can use this to supply the additional bits the decoder needs after we know the opcode of the instruction.
Finally, `InstrLenTable` is added to let the decoder know the length of the instructions.
See D120960 for its usage.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D120958
In commit ccf1469a4c lldb got its own generated Version.inc file, with
`LLDB_VERSION` macros. However, it used `LLDB_VERSION_PATCHLEVEL`
instead of the actually correct `LLDB_VERSION_PATCH`. Correct this.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124672
This syntax allows to modify RUN lines based on features
available. For example:
RUN: ... | FileCheck %s --check-prefix=%if windows %{CHECK-W%} %else %{CHECK-NON-W%}
CHECK-W: ...
CHECK-NON-W: ...
The whole command can be put under %if ... %else:
RUN: %if tool_available %{ %tool %} %else %{ true %}
or:
RUN: %if tool_available %{ %tool %}
If tool_available feature is missing, we'll have an empty command in
this RUN line. LIT used to emit an error for empty commands, but now
it treats such commands as nop in all cases.
Multi-line expressions are also supported:
RUN: %if tool_available %{ \
RUN: %tool \
RUN: %} %else %{ \
RUN: true \
RUN: %}
Background and motivation:
D121727 [NVPTX] Integrate ptxas to LIT tests
https://reviews.llvm.org/D121727
Differential Revision: https://reviews.llvm.org/D122569
When a unit test crashes or timeout, print the shard's stdout and
stderr. When a unit test fails, attaches the test's output to the LIT
output to help debugging.
While at it, concatenating shard's environment variables using space
instead of newline to make the reproducer script user friendly.
Based on D123797. (Thanks to @lenary)
The builtin predicate handling has a strange behavior where the code
assumes that a PatFrag is a stack of PatFrags, and each level adds at
most one predicate. I don't think this particularly makes sense,
especially without a diagnostic to ensure you aren't trying to set
multiple at once.
This wasn't followed for address spaces and alignment, which could
potentially fall through to report no builtin predicate was
added. Just switch these to follow the existing convention for now.
This teaches the perfect shuffle tables about lane inserts, that can
help reduce the cost of many entries. Many of the shuffle masks are
one-away from being correct, and a simple lane move can be a lot simpler
than trying to use ext/zip/etc. Because they are not exactly like the
other masks handled in the perfect shuffle tables, they require special
casing to generate them, with a special InsOp Operator.
The lane to insert into is encoded as the RHSID, and the move from is
grabbed from the original mask. This helps reduce the maximum perfect
shuffle entry cost to 3, with many more shuffles being generatable in a
single instruction.
Differential Revision: https://reviews.llvm.org/D123386
A brief introduction to perfect shuffles - AArch64 NEON has a number of
shuffle operations - dups, zips, exts, movs etc that can in some way
shuffle around the lanes of a vector. Given a shuffle of size 4 with 2
inputs, some shuffle masks can be easily codegen'd to a single
instruction. A <0,0,1,1> mask for example is a zip LHS, LHS. This is
great, but some masks are not so simple, like a <0,0,1,2>. It turns out
we can generate that from zip LHS, <0,2,0,2>, having generated
<0,2,0,2> from uzp LHS, LHS, producing the result in 2 instructions.
It is not obvious from a given mask how to get there though. So we have
a simple program (PerfectShuffle.cpp in the util folder) that can scan
through all combinations of 4-element vectors and generate the perfect
combination of results needed for each shuffle mask (for some definition
of perfect). This is run offline to generate a table that is queried for
generating shuffle instructions. (Because the table could get quite big,
it is limited to 4 element vectors).
In the perfect shuffle tables zip, unz and trn shuffles were being cost
as 2, which is higher than needed and skews the perfect shuffle tables
to create inefficient combinations. This sets them to 1 and regenerates
the tables. The codegen will usually be better and the costs should be
more precise (but it can get less second-order re-use of values from
multiple shuffles, these cases should be fixed up in subsequent patches.
Differential Revision: https://reviews.llvm.org/D123379
While working on D122986, noticed that indentation size varies even within
one file. Fixed that - now indentation is 2 spaces everywhere. This indentation
Differential Revision: https://reviews.llvm.org/D123859
Subj, or on other words, we have a lot of tests that are driven by
the LoopVectorizer's debug output, but we don't have
any meaningful way to autogenerate checklines in them,
which means that an insurmountable amount of manual work
is required when modifying the appropriate cost models.
That is not sustainable, so this presents a solution.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D121133
This patch makes possible generating NVPTX assembly check lines with
update_llc_test_checks.py utility.
Differential Revision: https://reviews.llvm.org/D122986
This helps lit unit test performance by a lot, especially on windows. The performance gain comes from launching one gtest executable for many subtests instead of one (this is the current situation).
The shards are executed by the test runner and the results are stored in the
json format supported by the GoogleTest. Later in the test reporting stage,
all test results in the json file are retrieved to continue the test results
summary etc.
On my Win10 desktop, before this patch: `check-clang-unit`: 177s, `check-llvm-unit`: 38s; after this patch: `check-clang-unit`: 37s, `check-llvm-unit`: 11s.
On my Linux machine, before this patch: `check-clang-unit`: 46s, `check-llvm-unit`: 8s; after this patch: `check-clang-unit`: 7s, `check-llvm-unit`: 4s.
Reviewed By: yln, rnk, abrachet
Differential Revision: https://reviews.llvm.org/D122251
This reverts the functional changes of D103427 but keeps its tests, and
and reimplements the functionality by reusing the existing 32-bit
MASKMOVDQU and VMASKMOVDQU instructions as suggested by skan in review.
These instructions were previously predicated on Not64BitMode. This
reimplementation restores the disassembly of a class of instructions,
which will see a test added in followup patch D122449.
These instructions are in 64-bit mode special cased in
X86MCInstLower::Lower, because we use flags with one meaning for subtly
different things: we have an AdSize32 class which indicates both that
the instruction needs a 0x67 prefix and that the text form of the
instruction implies a 0x67 prefix. These instructions are special in
needing a 0x67 prefix but having a text form that does *not* imply a
0x67 prefix, so we encode this in MCInst as an instruction that has an
explicit address size override.
Note that originally VMASKMOVDQU64 was special cased to be excluded from
disassembly, as we cannot distinguish between VMASKMOVDQU and
VMASKMOVDQU64 and rely on the fact that these are indistinguishable, or
close enough to it, at the MCInst level that it does not matter which we
use. Because VMASKMOVDQU now receives special casing, even though it
does not make a difference in the current implementation, as a
precaution VMASKMOVDQU is excluded from disassembly rather than
VMASKMOVDQU64.
Reviewed By: RKSimon, skan
Differential Revision: https://reviews.llvm.org/D122540
This commit contains a refactoring that merges AVRRelaxMemOperations
into AVRExpandPseudoInsts, so that we have a single place in code that
expands the STDWPtrQRr opcode.
Seizing the day, I've also fixed a couple of potential bugs with our
previous implementation (e.g. when the destination register was killed,
the previous implementation would try to .addDef() that killed
register, crashing LLVM in the process - that's fixed now, as proved by
the test).
Reviewed By: benshi001
Differential Revision: https://reviews.llvm.org/D122533
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
This reverts commit 3f0587d0c6.
Not all tests pass after a few rounds of fixes.
I spot one failure that std::shuffle (potentially different results with
different STL implementations) was misused and replaced it with llvm::shuffle,
but there appears to be another failure in a Windows build.
The latest failure is reported on https://reviews.llvm.org/D121556#3440383
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
Our support for building for baremetal was conditional on a default
off arg and would have failed to build if you had somehow arranged
to pass the correct --target flag; presumably nobody noticed because
nobody was turning it on. A better approach is to model baremetal
as a separate "OS" called "baremetal" and build it in the same way
as we cross-compile for other targets. That's what this patch does.
I only hooked up the arm64 target but others can be added.
Relanding after fixing Mac build breakage in D123244.
Differential Revision: https://reviews.llvm.org/D122862
When cross-compiling from Mac to non-Mac, we need to use the just-built
llvm-ar instead of libtool. We're currently doing the right thing
when determining which archiver command to use, but the path to ar
and the toolchain dependencies were being set based on the host OS
(current_os evaluated in host OS toolchain), instead of the target
OS. Fix the problem by looking up current_os inside toolchain_args.
Differential Revision: https://reviews.llvm.org/D123244
Our support for building for baremetal was conditional on a default
off arg and would have failed to build if you had somehow arranged
to pass the correct --target flag; presumably nobody noticed because
nobody was turning it on. A better approach is to model baremetal
as a separate "OS" called "baremetal" and build it in the same way
as we cross-compile for other targets. That's what this patch does.
I only hooked up the arm64 target but others can be added.
Differential Revision: https://reviews.llvm.org/D122862
```
{X86::MOVLHPSrr,X86::MOVHPSrm}
{X86::VMOVLHPSZrr,X86::VMOVHPSZ128rm}
{X86::VMOVLHPSrr,X86::VMOVHPSrm}
```
Each of the three pairs has different mnemonic, so we have to add it
manually. This is a follow-up patch for D122477.
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
Add void casts to mark the variables used, next to the places where
they are used in assert or `LLVM_DEBUG()` expressions.
Differential Revision: https://reviews.llvm.org/D123117
Intuitively, the memory folding pair should have the same mnemonic.
This patch removes
```
{X86::SENDUIPI,X86::VMXON}
```
in the auto-generated table.
And `NotMemoryFoldable` for `TPAUSE` and `CLWB` can be saved.
```
{X86::MOVLHPSrr,X86::MOVHPSrm}
{X86::VMOVLHPSZrr,X86::VMOVHPSZ128rm}
{X86::VMOVLHPSrr,X86::VMOVHPSrm}
```
It seems the three pairs above are mistakenly killed.
But we can add them back manually later.
Reviewed By: Amir
Differential Revision: https://reviews.llvm.org/D122477
This is a no-op in these files since the symlinks array is never empty
and the dependency to the base binary is added through the loop in these
cases.
But adding them doesn't hurt either, and it:
1. Makes all symlinks targets look the same, independent of symlinks
are created always or just conditionally based on gn args
2. Makes it less likely that bugs like the one fixed by b0abada8fe
are introduced by copy-pasting an existing symlink target and then
not being careful enough when tweaking it.
No behavior change.
This fixes a regression from 69cde915e923d: If llvm_install_cctools_symlinks
is false, depending llvm-lipo:symlinks didn't actually depend on llvm-lipo
and the binary didn't get built as dependency of `check-lld` (because the
`symlinks` array ended up empty).
This helps lit unit test performance by a lot, especially on windows. The performance gain comes from launching one gtest executable for many subtests instead of one (this is the current situation).
The shards are executed by the test runner and the results are stored in the
json format supported by the GoogleTest. Later in the test reporting stage,
all test results in the json file are retrieved to continue the test results
summary etc.
On my Win10 desktop, before this patch: `check-clang-unit`: 177s, `check-llvm-unit`: 38s; after this patch: `check-clang-unit`: 37s, `check-llvm-unit`: 11s.
On my Linux machine, before this patch: `check-clang-unit`: 46s, `check-llvm-unit`: 8s; after this patch: `check-clang-unit`: 7s, `check-llvm-unit`: 4s.
Reviewed By: yln, rnk
Differential Revision: https://reviews.llvm.org/D122251
This flag silents the build output of test-release.sh so that
it can be used in CI systems a bit better. It will still log
the build output to the log files but not echo it to stdout.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D122146
This lets the revert_checker.py get called with the -u option, which
formats the revert and reverted SHAs into handy URLs which point to the
LLVM reviews associated with those SHAs. This is useful for viewers to
look quickly at the changes made by SHAs that were potentially reverted.
Differential Revision: https://reviews.llvm.org/D122772
It was already the case for CLI help, also support it for rst output. As a side
effect remove redundant (and sometime inconsistent!) value help from HelpText in
clang/Driver/Options.td.
Differential Revision: https://reviews.llvm.org/D122378
1. Add comments to explain why we set `isAsmParserOnly` for XACQUIRE and XRELEASE
2. Check `X86Inst` in the constructor of `RecognizableInstrBase` so that
we can avoid the case where one of it's field is not initialized but
accessed by user. (e.g. in X86EVEX2VEXTablesEmitter.cpp)
3. Move `Rec` from `RecognizableInstrBase` to `RecognizableInstr` to reduce
size of `RecognizableInstrBase`
4. Remove out-of-date comments for shouldBeEmitted() (filter() was removed)
5. Add a basic field `IsAsmParserOnly` and remove the field
`ShouldBeEmitted` b/c we can deduce it w/ little overhead
In fact, an instruction can not be emitted to disassemble table when
`isAsmParserOnly` is true, so `isAsmParserOnly=true` implies
`ShouldBeEmitted=false`.
We check `isAsmParserOnly` in X86FoldTablesEmitter.cpp at a early stage
b/c none of them is foldable.
All LLVM backends use MCDisassembler as a base class for their
instruction decoders. Use "const MCDisassembler *" for the decoder
instead of "const void *". Remove unnecessary static casts.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D122245
CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.
Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().
This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
- there's nothing clang-specific about the value
- it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)
It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e24d, there are LLD_LIBS_DIR usages etc that
may be live, and I'd like to mechanically update them in a followup patch.
Differential Revision: https://reviews.llvm.org/D121763
It's unusual that BLAKE3/CMakeLists.txt just defines a list of
files that it injects into its parent scope. The list should either
be defined in llvm/lib/Support/CMakeLists.txt, or
llvm/lib/Support/BLAKE3/CMakeLists.txt should define an object
library.
This does the latter. It makes llvm/lib/Support/BLAKE3/CMakeLists.txt
more self-contained.
No behavior change.
Differential Revision: https://reviews.llvm.org/D122428
This is legacy PM-specific, which is deprecated.
Uses of this should be replaced with a corresponding `-passes='print<foo>'`.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D122420
Most intrinsics, especially "default" ones, will not call back into the
IR module. `nocallback` encodes this nicely. As it was not used before,
this patch also makes use of `nocallback` in the Attributor which
results in many more `norecurse` deductions.
Tablegen part is mechanical, test updates by script.
Differential Revision: https://reviews.llvm.org/D118680
macOS 12.3 no longer ships non-3 python.
Almost all of these scripts were launched by ninja, and the GN files
already told it to run them under python3, so this is a fairly small
change. The main effect is that if you run them manually, you now
get the same behavior.
(A small set of scripts, gn.py, gen.py, sync_source_lists_from_cmake.py,
are for manual running. For these, it is an actual change.)
Differential Revision: https://reviews.llvm.org/D122345
It behaves (mostly) like the LLVM_INSTALL_CCTOOLS_SYMLINKS option
in cmake.
The minor difference is that the llvm-objcopy symlinks bitcode_strip
and install_name_tool symlink to llvm-objcopy directly in the GN build,
while it's a bitcode_strip -> llvm-bitcode-strip -> objcopy chain
in the CMake build (and analogous for install_name_tool).
The implementation is very similar to the implementation of the
existing llvm_install_binutils_symlinks arg.
Differential Revision: https://reviews.llvm.org/D122312
CoroSplit lowers various coroutine intrinsics. It's a CGSCC pass and
CGSCC passes don't run on unreachable functions. Normally GlobalDCE will
come along and delete unreachable functions, but we don't run GlobalDCE
under -O0, so an unreachable function with coroutine intrinsics may
never have CoroSplit run on it.
This patch adds GlobalDCE when coroutines intrinsics are present. It
also now runs all coroutine passes conditional when coroutine intrinsics
are present. This should also solve the -O0 regression reported in
D105877 due to LazyCallGraph construction.
Fixes https://github.com/llvm/llvm-project/issues/54117
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D122275
Debian8 is too old to build LLVM project, the version
of GCC, CMake and python are lower than the requirements:
https://llvm.org/docs/GettingStarted.html#software
Debian10 is the earliest release that has software
packages that meet the above requirements.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D120826
The mask being NoRegister prevented the existing aliases from matching
since NoRegister isn't in the VMV0 register class.
To workaround this I've added new aliases that look for zero_reg.
I had to motify tablegen to generate matching code for zero_reg.
And as a consequence, I had to change the EmitPriority for an ARM
alias that used zero_reg that started printing.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D121496
This adds LLVMAnyPointerToElt to use instead of LLVMPointerToElt.
This allows us to preserve the address space as part of the type
overload for the intrinsic, but still require the vector element
type to match the pointer type.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D122042
`getValueAsBitsInit` will assert when the "SoftFail" isn't presented.
But given the 'if' statement below, we should've allowed this situation.
This patch fix this.
If `clang_base_path` is set, it must now point to a directory that contains
an lld-link built with D118070.
(If this is a problem for anyone, we can guard this behind a
lld_link_understands_winsysroot gn arg, but let's see if we can get away
without that for now.)
With this, it's possible to build everything in a normal cmd.exe Window,
an MSVC shell isn't needed \o/
(Assuming you set `clang_base_path`, and you set `sysroot` to a directory
that contains a win sysroot. If you have MSVC installed,
`python3 llvm\utils\sysroot.py make-fake --out-dir=my-sysroot` and
setting `sysroot = "//my-sysroot"` in args.gn works, for example.)
Differential Revision: https://reviews.llvm.org/D121871
Fix an issue reported by UBSan.
Test Plan:
Configure with `-DLLVM_USE_SANITIZER="Address;Undefined"`
`ninja llc`
Differential Revision: https://reviews.llvm.org/D122140
The solution using append was reported not to work, but additionally it
would use the contents of the checked-out source tree instead of the git
tag or commit. This uses `git archive`, so it will use the right commit,
and at least for me (with GNU tar) it seems to work as intended.
Should fix#53281.
Reviewed By: kwk
Differential Revision: https://reviews.llvm.org/D121972
%S refers to the directory of %s, not to the cwd. This is mostly
handled correctly, but update_cc_test_checks.py used the wrong
path for non-FileCheck RUN lines.
Reapplying this with a fix for an update_cc_test_checks test that
was based on cwd semantics.
%S refers to the directory of %s, not to the cwd. This is mostly
handled correctly, but update_cc_test_checks.py used for the wrong
path for non-FileCheck RUN lines.
Reland of D120906 after sanitizer failures.
This patch aims to reduce a lot of the boilerplate around adding new subtarget
features. From the SubtargetFeatures tablegen definitions, a series of calls to
the macro GET_SUBTARGETINFO_MACRO are generated in
ARM/AArch64GenSubtargetInfo.inc. ARMSubtarget/AArch64Subtarget can then use
this macro to define bool members and the corresponding getter methods.
Some naming inconsistencies have been fixed to allow this, and one unused
member removed.
This implementation only applies to boolean members; in future both BitVector
and enum members could also be generated.
Differential Revision: https://reviews.llvm.org/D120906
LLVM GN Syncbot