Summary:
Terminology introduced by [[#]] blocks is confusing and does not
integrate well with existing terminology.
First, variables referred by [[]] blocks are called "pattern variables"
while the text a CHECK directive needs to match is called a "CHECK
pattern". This is inconsistent with variables in [[#]] blocks since
[[#]] blocks are also found in CHECK pattern yet those variables are
called "numeric variable".
Second, the replacing of both [[]] and [[#]] blocks by the value of the
variable or expression they contain is represented by a
FileCheckPatternSubstitution class. The naming refers to being a
substitution in a CHECK pattern but could be wrongly understood as being
a substitution of a pattern variable.
Third and lastly, comments use "numeric expression" to refer both to the
[[#]] blocks as well as to the numeric expressions these blocks contain
which get evaluated at match time.
This patch solves these confusions by
- calling variables in [[]] and [[#]] blocks as string and numeric
variables respectively;
- referring to [[]] and [[#]] as substitution *blocks*, with the former
being a string substitution block and the latter a numeric
substitution block;
- calling [[]] and [[#]] blocks to be replaced by the value of a
variable or expression they contain a substitution (as opposed to
definition when these blocks are used to defined a variable), with the
former being a string substitution and the latter a numeric
substitution;
- renaming the FileCheckPatternSubstitution as a FileCheckSubstitution
class with FileCheckStringSubstitution and
FileCheckNumericSubstitution subclasses;
- restricting the use of "numeric expression" to refer to the expression
that is evaluated in a numeric substitution.
While numeric substitution blocks only support numeric substitutions of
numeric expressions at the moment there are plans to augment numeric
substitution blocks to support numeric definitions as well as both a
numeric definition and numeric substitution in the same numeric
substitution block.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, arichardson, probinson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62146
llvm-svn: 361445
Summary:
Another target that prefers to use `-march` in tests
```
llvm/test/CodeGen/SPARC$ grep -ri mtriple | wc -l
25
llvm/test/CodeGen/SPARC$ grep -ri march | wc -l
165
```
This test is being affected by a further patch,
so regenerate it to better visualize the changes
Reviewers: RKSimon, dcederman, gberry
Reviewed By: RKSimon
Subscribers: jyknight, fedor.sergeev, jrtc27, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62242
llvm-svn: 361381
r360889 added new llround builtin functions. This patch adds their
signatures for the WebAssembly backend.
It also adds wasm32 support to utils/update_llc_test_checks.py, since
that's the script other targets are using for their testcases for this
feature.
Differential Revision: https://reviews.llvm.org/D62207
llvm-svn: 361327
Summary:
Was looking into supporting `(srl (shl x, c1), c2)` with c1 != c2 in dagcombiner,
this test changes, but makes `update_llc_test_checks.py` unhappy.
**Many** AMDGPU tests specify `-march`, not `-mtriple`, which results in `update_llc_test_checks.py`
defaulting to x86 asm function detection heuristics, which don't work here.
I propose to fix this by adding an infrastructure to map from `-march` to `-mtriple`,
in the UpdateTestChecks tooling.
Reviewers: RKSimon, MaskRay, arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62099
llvm-svn: 361101
Summary:
Was looking into supporting `(srl (shl x, c1), c2)` with c1 != c2 in dagcombiner,
this test changes, but makes `update_llc_test_checks.py` unhappy
Reviewers: RKSimon
Reviewed By: RKSimon
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62097
llvm-svn: 361100
zlib/nozlib, asan/not_asan, msan/not_msan, ubsan/not_ubsan.
We still have two other ways to express the absence of a feature.
First, we have the '!' operator to invert the sense of a keyword. For
example, given a feature that depends on zlib being unavailable, its
test can say:
REQUIRES: !zlib
Second, if a test doesn't play well with some features, such as
sanitizers, that test can say:
UNSUPPORTED: asan, msan
The different ways of writing these exclusions both have the same
technical effect, but have different implications to the reader.
llvm-svn: 360603
The tablegen groups only need public_deps for inc files included
(possibly transitively) in other targets. Move inc files that are
internan to the MCTargetDesc libraries into regular deps.
Related to the changes that merged InstPrinter into MCTargetDesc
(360484, 360486 etc).
llvm-svn: 360600
This commit appears to be breaking stage-2 builds on GreenDragon. The
OpenMP wrappers for cmath and math.h are copied into the root of the
resource directory and cause a cyclic dependency in module 'Darwin':
Darwin -> std -> Darwin. This blows up when CMake is testing for modules
support and breaks all stage 2 module builds, including the ThinLTO bot
and all LLDB bots.
CMake Error at cmake/modules/HandleLLVMOptions.cmake:497 (message):
LLVM_ENABLE_MODULES is not supported by this compiler
llvm-svn: 360192
Summary:
This reverts commit r360106.
The revisioin causes llvm-tblgen to hang while generating info for
RISCV.td. The root cause might be in the RISCV.td definition but I don't
know enough about this to investigate further.
Command that starts hangning after r360106:
`llvm-build/bin/llvm-tblgen -I llvm/include -I llvm/tools/clang/include -I llvm/lib/Target/RISCV -gen-instr-info llvm/lib/Target/RISCV/RISCV.td`
Reviewers: sammccall, yan_luo, craig.topper, gribozavr
Reviewed By: gribozavr
Subscribers: PkmX, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61632
llvm-svn: 360136
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61572
llvm-svn: 360004
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61571
llvm-svn: 360003
Not all versions of git support git rev-parse --git-common-dir. Rather than erorr or print any kind of
useful error, they just print back '--git-common-dir' instead of a directory. The git-llvm script
ends up taking this '--git-common-dir' as a diretory name to use.
Not sure exactly what happens after that, but the end result is that the 'git llvm push' ends up
looking like it pushed your commits, but really did nothing.
This patch makes the script detect the bogus directory name for --git-common-dir and falls back to using --git-dir instead.
llvm-svn: 359939
This change introduces support for building libc++. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D61143
llvm-svn: 359806
This change introduces support for building libcxxabi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60372
llvm-svn: 359805
This change introduces support for building libuwind. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60370
llvm-svn: 359804
The Tooling tests do have a lit.local.cfg with
if not config.root.clang_staticanalyzer:
config.unsupported = True
so what's wrong isn't the missing dep, but that lit prints a warning for
the binary missing. This will need a different kind of fix.
llvm-svn: 359739
check-clang (the target that runs all clang tests) used to
only depend on clang-check (a binary like clang-tidy,
clang-refactor, etc) if the static analyzer is enabled.
However, several lit tests call clang-check unconditionally,
so always depend on it.
Fixes a "could not find clang-check" lit warning in clean builds with
the static analyzer disabled.
Also sort the deps in the CMake file and put just one dep on each line.
Differential Revision: https://reviews.llvm.org/D61324
llvm-svn: 359717
Summary:
Various tests in the `lit` testing suite expect specific return codes
and forms of diagnostic message from utility programs. As per
POSIX.1-2017 XCU Section 1.4, Utility Description Defaults, "[the]
format of diagnostic messages for most utilities is unspecified".
The STDERR subsections of the `cat` and `wc` utilities merely indicate
that "[the] standard error shall be used only for diagnostic messages".
The corresponding EXIT STATUS subsections merely indicate, with regard
to errors, an exit value of >0.
The affected tests are updated to accept the applicable diagnostic
message as produced by the utilities on AIX. The exit value is
normalized using `not` as necessary.
Reviewers: xingxue, sfertile, jasonliu
Reviewed By: xingxue
Subscribers: delcypher, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60553
llvm-svn: 359690
r359527 already merged some of that to the GN build,
but it was missing some bits as well.
The check-clangd target works (at least for now) differently than all
the other check-foo targets, see https://reviews.llvm.org/D61187
For that reason, there's no gni file and the generated lit configs are
not (yet?) added to llvm-lit/BUILD.gn.
llvm-svn: 359570
On mingw/i686, local labels don't start with a leading period.
Also escape the leading period, as it previously could match
any char.
Differential Revision: https://reviews.llvm.org/D61254
llvm-svn: 359497
Multiple targets in the same output directory can use the same
target_output_name. The typical example of that is having a shared
and a static library of the same, e.g. libc++.so and libc++.a.
When that's the case, the object files produced for each target
are going to conflict. Using the label_name avoids this conflict
since labels are guaranteed to be unique within a single BUILD.gn
file which corresponds to a single output directory.
Differential Revision: https://reviews.llvm.org/D60329
llvm-svn: 359494
If this is set, %INCLUDE% must contain ".../DIA SDK/include"
and %LIB% must contain ".../DIA SKD/lib/amd64" (assuming you're doing a
64-bit build).
llvm-svn: 359195
Since the symlinks list for llvm-symbolizer is now never empty,
the :symlinks target no longer needs an explicit dep on :llvm-symbolizer
-- there will be at least one dep on a symlink, and each symlink depends
on :llvm-symbolizer already.
Since llvm-symbolizer:symlinks now produces symlinks that check-llvm
uses, make llvm/test depend on the symlink target.
llvm-svn: 358861
ClangdLSPServer and clangd unittests now include Features.inc so we
need to append the target_gen_dir that contains it to their
include_dirs. To do so, we use a public config that's applied to
any target that depends on the features one.
Differential Revision: https://reviews.llvm.org/D60919
llvm-svn: 358837
Summary:
Previously, write_cmake_config.py would raise an error while printing
the error, because `leftovers` in "'\n'.join(leftovers)" is a tuple.
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60766
llvm-svn: 358557
If you have more than one schedule model in your TableGen target
definitions, then the diagnostic "No schedule information for
instruction 'foo'" is rather unhelpful, because it doesn't tell you
_which_ schedule model is missing the necessary information (or, as it
might be, missing the UnsupportedFeatures definition that would stop
it thinking it needed it).
Extended the message to include the name of the schedule model that
it's complaining about.
Reviewers: nhaehnle, hfinkel, javedabsar, efriedma, javed.absar
Reviewed By: javed.absar
Subscribers: javed.absar, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60559
llvm-svn: 358389
Add a 'target-x86' and 'target-x86_64' feature sthat indicates that
the default target is 32-bit or 64-bit x86, appropriately. Combined
with 'native' feature, we're going to use this to control x86-specific
LLDB native process tests.
Differential Revision: https://reviews.llvm.org/D60474
llvm-svn: 358177
Summary:
```
``!listsplat(a, size)``
A list value that contains the value ``a`` ``size`` times.
Example: ``!listsplat(0, 2)`` results in ``[0, 0]``.
```
I plan to use this in X86ScheduleBdVer2.td for LoadRes handling.
This is a little bit controversial because unlike every other binary operator
the types aren't identical.
Reviewers: stoklund, javed.absar, nhaehnle, craig.topper
Reviewed By: javed.absar
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60367
llvm-svn: 358117
The composite existed to simplify some other tablegen code and not really in an
important way. Remove the combined field and just calculate the vector size
using two ifs.
llvm-svn: 357972
The instruction's document this as W0 for the VEX encoding. But there's a
footnote mentioning that VEX.W is ignored in 64-bit mode. And the main VEX
encoding description says the VEX.W bit is ignored for instructions that are
equivalent to a legacy SSE instruction that uses REX.W to select a GPR which
would apply here.
By making this match EVEX we can remove a special case of allowing EVEX2VEX to
turn an EVEX.WIG instruction into VEX.W0.
llvm-svn: 357971
This change also introduces the clang_enable_per_target_runtime_dir
to enable the use of per-target runtime directory layout which is the
equivalent of LLVM_ENABLE_PER_TARGET_RUNTIME_DIR CMake option.
Differential Revision: https://reviews.llvm.org/D60332
llvm-svn: 357850
This is support for building compiler-rt builtins, The library build
should be complete for a subset of supported platforms, but not all
CMake options have been replicated in GN.
We always use the just built compiler to build all the runtimes, which
is equivalent to the CMake runtimes build. This simplifies the build
configuration because we don't need to support arbitrary host compiler
and can always assume the latest Clang. With GN's toolchain support,
this is significantly more efficient than the CMake runtimes build.
Differential Revision: https://reviews.llvm.org/D60331
llvm-svn: 357821
Summary:
This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between Jcc instructions and condition codes.
Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser.
Reviewers: spatel, lebedev.ri, courbet, gchatelet, RKSimon
Reviewed By: RKSimon
Subscribers: MatzeB, qcolombet, eraman, hiraditya, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60228
llvm-svn: 357802
Summary:
This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between SETcc instructions and condition codes.
Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser.
Reviewers: andreadb, courbet, RKSimon, spatel, lebedev.ri
Reviewed By: andreadb
Subscribers: hiraditya, lebedev.ri, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60138
llvm-svn: 357801
Summary:
Reorder the condition code enum to match their encodings. Move it to MC layer so it can be used by the scheduler models.
This avoids needing an isel pattern for each condition code. And it removes
translation switches for converting between CMOV instructions and condition
codes.
Now the printer, encoder and disassembler take care of converting the immediate.
We use InstAliases to handle the assembly matching. But we print using the
asm string in the instruction definition. The instruction itself is marked
IsCodeGenOnly=1 to hide it from the assembly parser.
This does complicate the scheduler models a little since we can't assign the
A and BE instructions to a separate class now.
I plan to make similar changes for SETcc and Jcc.
Reviewers: RKSimon, spatel, lebedev.ri, andreadb, courbet
Reviewed By: RKSimon
Subscribers: gchatelet, hiraditya, kristina, lebedev.ri, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60041
llvm-svn: 357800
We should be always rebasing paths against root_build_dir which is
the directory where scripts are run from, not root_out_dir which is
the current toolchain directory. The latter can result in invalid
paths when the action is being used from a non-default toolchain.
Differential Revision: https://reviews.llvm.org/D60330
llvm-svn: 357798
This allows it to be disabled for targets that need exceptions
like libunwind, libc++abi and libc++.
Differential Revision: https://reviews.llvm.org/D60328
llvm-svn: 357797
Use ctypes to call into SHFileOperationW with the extended NT path to allow us
to remove paths which exceed 261 characters on Windows. This functionality is
exercised by swift's test suite.
llvm-svn: 357778
Summary:
This avoids the need to talk about lib.exe or llvm-lib.exe and it does
the right thing with LLD.
Reviewers: thakis
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60155
llvm-svn: 357660
None of check-clang-tools's tests run this, but the CMake
check-clang-tools depends on the binary, so add it for consistency.
Differential Revision: https://reviews.llvm.org/D60222
llvm-svn: 357624
This is a bit of a larger change since this is the first (and as far as
I can tell only) place where the LLVM build produces macOS framework
bundles.
GN has some built-in support for this, so use that.
`gn help create_bundle` has a terse description (but it's a bit
outdated: `deps` must be `public_deps` and the conditionals in the
example in the help aren't quite right on non-iOS).
We need a new 'copy_bundle_data' tool, and since we copy the clangd.xpc
bundle as bundle_data into ClangdXPC.framework it needs to be able to
handle directories in addition to files.
GN also insists we have a compile_xcassets tool even though it's not
used. I just made that run `false`.
Despite GN's support for bundles, we still need to manually create the
expected symlink structure in the .framework bundle. Since this code
never runs on Windows, it's safe to create the symlinks before the
symlink targets exist, so we can just make the bundle depend on the
steps that create the symlinks. For this to work, change the symlink
script to create the symlink's containing directory if it doesn't yet
exist.
I locally verified that CMake and GN build create the same bundle
structure. (I noticed that both builds set LC_ID_DYLIB to the pre-copy
libClangdXPCLib.dylib name, but that seems to not cause any issues and
it happens in the CMake build too.)
(Also add an error message to clangd-xpc-test-client for when loading
the dylib fails – this was useful while locally debugging this.)
Differential Revision: https://reviews.llvm.org/D60130
llvm-svn: 357574
We were using the number of Matchables rather than the number of rows in the converter table.
This only matters for a few of the targets where the number of matchables is more than 255, but the number of converters is less than 255. Many of the targets have more than 256 converters. So already required a uint16_t.
llvm-svn: 357527
Both LLVM 8.0.0 and current trunk fail to compile on Solaris with GCC 8.1.0:
/vol/llvm/src/llvm/dist/utils/FileCheck/FileCheck.cpp: In function ‘void DumpAnnotatedInput(llvm::raw_ostream&, const llvm::FileCheckRequest&, llvm::StringRef, std::vector<InputAnnotation>&, unsigned int)’:
/vol/llvm/src/llvm/dist/utils/FileCheck/FileCheck.cpp:408:41: error: call of overloaded ‘log10(unsigned int&)’ is ambiguous
unsigned LineNoWidth = log10(LineCount) + 1;
^
In file included from /vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/math.h:24,
from /vol/gcc-8/include/c++/8.1.0/cmath:45,
from /vol/llvm/src/llvm/dist/include/llvm-c/DataTypes.h:28,
from /vol/llvm/src/llvm/dist/include/llvm/Support/DataTypes.h:16,
from /vol/llvm/src/llvm/dist/include/llvm/ADT/Hashing.h:47,
from /vol/llvm/src/llvm/dist/include/llvm/ADT/ArrayRef.h:12,
from /vol/llvm/src/llvm/dist/include/llvm/Support/CommandLine.h:22,
from /vol/llvm/src/llvm/dist/utils/FileCheck/FileCheck.cpp:18:
/vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/iso/math_iso.h:209:21: note: candidate: ‘long double std::log10(long double)’
inline long double log10(long double __X) { return __log10l(__X); }
^~~~~
/vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/iso/math_iso.h:170:15: note: candidate: ‘float std::log10(float)’
inline float log10(float __X) { return __log10f(__X); }
^~~~~
/vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/iso/math_iso.h:70:15: note: candidate: ‘double std::log10(double)’
extern double log10 __P((double));
^~~~~
Fixed by using std::log10 instead, which allowed the compilation on i386-pc-solaris2.11
and sparc-sun-solaris2.11 to continue.
Differential Revision: https://reviews.llvm.org/D60043
llvm-svn: 357509
Only runs the clang-tools-extra lit tests; not yet the unit tests.
Add a build file for clangd-indexer too, since it's needed for
the tests.
Differential Revision: https://reviews.llvm.org/D59955
llvm-svn: 357232
Summary:
It does not currently make sense to use WebAssembly features in some functions
but not others, so this CL adds an IR pass that takes the union of all used
feature sets and applies it to each function in the module. This allows us to
prevent atomics from being lowered away if some function has opted in to using
them. When atomics is not enabled anywhere, we detect whether there exists any
atomic operations or thread local storage that would be stripped and disallow
linking with objects that contain atomics if and only if atomics or tls are
stripped. When atomics is enabled, mark it as used but do not require it of
other objects in the link. These changes allow libraries that do not use atomics
to be built once and linked into both single-threaded and multithreaded
binaries.
Reviewers: aheejin, sbc100, dschuff
Subscribers: jgravelle-google, hiraditya, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59625
llvm-svn: 357226
Enough to build the clangd binaries, but this is still missing build
files for:
- fuzzer
- indexer
- index/dex/dexp
- benchmarks
- xpc
Differential Revision: https://reviews.llvm.org/D59899
llvm-svn: 357182
Summary:
The current git-svnrevert script only works with git-svn repos (e.g. using "git svn find-rev" to find the commit to revert). This adds a similar implementation that works with the llvm git command handler.
Usage:
```
// Revert by svn id
$ git llvm revert r123456
// See what commands would be run instead of actually reverting
$ git llvm revert -n r123456
<full git revert + git commit commands>
// Git commit hash also fine
$ git llvm revert abc123456
// For convenience, the git->svn method can be used directly:
$ git llvm svn-lookup abc123456
r123456
// Push revert upstream (drop the -n when ready)
$ git llvm push -n
```
Regardless of how the command is invoked (with a svn revision or git hash), the message is:
```
Revert [LibFoo] Change Foo implementation
This reverts r123456 (git commit abc123)
```
Reviewers: jyknight, mehdi_amini, jlebar
Reviewed By: jlebar
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59837
llvm-svn: 357180
- Make introduction a bit shorter
- Add a `git clone` step to Quick start
- Put command to run first in each of the Quick start steps
- Use ``code`` instead of `label` throughout; this is .rst not .md
Differential Revision: https://reviews.llvm.org/D59600
llvm-svn: 356885
The zip is small, and it's a bit less code this way.
No intended behavior change.
Differential Revision: https://reviews.llvm.org/D59677
llvm-svn: 356884
In all the other clang-foo tools, the main library file is called
Foo.cpp and the file in the tool/ folder is called ClangFoo.cpp.
Do this for clang-move too.
No intended behavior change.
Differential Revision: https://reviews.llvm.org/D59700
llvm-svn: 356780
As discovered in D56774 the command line gets to long, so use a response file
to give the script the libs. This change has been tested and is confirmed
working for me.
Commited on behalf of Jakob Bornecrantz.
Differential Revision: https://reviews.llvm.org/D56781
llvm-svn: 356443
These were added in r355423.
We only use the autogenerated table to assist with the maintenance of the
manual table. These entries are alreayd in the manual table.
llvm-svn: 356357
AMDGPU would like to use these MVTs.
Differential Revision: https://reviews.llvm.org/D58901
Change-Id: I6125fea810d7cc62a4b4de3d9904255a1233ae4e
llvm-svn: 356351
Previously we had a regular form of the instruction used when the immediate was 0-7. And _alt form that allowed the full 8 bit immediate. Codegen would always use the 0-7 form since the immediate was always checked to be in range. Assembly parsing would use the 0-7 form when a mnemonic like vpcomtrueb was used. If the immediate was specified directly the _alt form was used. The disassembler would prefer to use the 0-7 form instruction when the immediate was in range and the _alt form otherwise. This way disassembly would print the most readable form when possible.
The assembly parsing for things like vpcomtrueb relied on splitting the mnemonic into 3 pieces. A "vpcom" prefix, an immediate representing the "true", and a suffix of "b". The tablegenerated printing code would similarly print a "vpcom" prefix, decode the immediate into a string, and then print "b".
The _alt form on the other hand parsed and printed like any other instruction with no specialness.
With this patch we drop to one form and solve the disassembly printing issue by doing custom printing when the immediate is 0-7. The parsing code has been tweaked to turn "vpcomtrueb" into "vpcomb" and then the immediate for the "true" is inserted either before or after the other operands depending on at&t or intel syntax.
I'd rather not do the custom printing, but I tried using an InstAlias for each possible mnemonic for all 8 immediates for all 16 combinations of element size, signedness, and memory/register. The code emitted into printAliasInstr ended up checking the number of operands, the register class of each operand, and the immediate for all 256 aliases. This was repeated for both the at&t and intel printer. Despite a lot of common checks between all of the aliases, when compiled with clang at least this commonality was not well optimized. Nor do all the checks seem necessary. Since I want to do a similar thing for vcmpps/pd/ss/sd which have 32 immediate values and 3 encoding flavors, 3 register sizes, etc. This didn't seem to scale well for clang binary size. So custom printing seemed a better trade off.
I also considered just using the InstAlias for the matching and not the printing. But that seemed like it would add a lot of extra rows to the matcher table. Especially given that the 32 immediates for vpcmpps have 46 strings associated with them.
Differential Revision: https://reviews.llvm.org/D59398
llvm-svn: 356343
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356029
This indicates an intrinsic parameter is required to be a constant,
and should not be replaced with a non-constant value.
Add the attribute to all AMDGPU and generic intrinsics that comments
indicate it should apply to. I scanned other target intrinsics, but I
don't see any obvious comments indicating which arguments are intended
to be only immediates.
This breaks one questionable testcase for the autoupgrade. I'm unclear
on whether the autoupgrade is supposed to really handle declarations
which were never valid. The verifier fails because the attributes now
refer to a parameter past the end of the argument list.
llvm-svn: 355981
Summary:
I'm trying to push D59198 but it seems that `git-llvm push` can't handle the fact
that I add a new directory in the patch:
```
> git llvm push -n
Pushing 1 commit:
e7c0a9bd136 Correctly look up declarations in inline namespaces
Traceback (most recent call last):
File "llvm/utils/git-svn//git-llvm", line 431, in <module>
args.func(args)
File "llvm/utils/git-svn//git-llvm", line 385, in cmd_push
clean_svn(svn_root)
File "llvm/utils/git-svn//git-llvm", line 201, in clean_svn
os.remove(os.path.join(svn_repo, filename))
IsADirectoryError: [Errno 21] Is a directory: '.git/llvm-upstream-svn/lldb/trunk/packages/Python/lldbsuite/test/expression_command/inline-namespace'
```
This patch just uses shutil to delete the directory instead of trying to use `os.remove`
which only works for files.
Reviewers: mehdi_amini, jlebar
Reviewed By: jlebar
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59236
llvm-svn: 355896
It hasn't seen active development in years, and it hasn't reached a
state where it was useful.
Remove the code until someone is interested in working on it again.
Differential Revision: https://reviews.llvm.org/D59133
llvm-svn: 355862
AMDGPU target run out of Subtarget feature flags hitting the limit of 64.
AssemblerPredicates uses at most uint64_t for their representation.
At the same time CodeGen has exhausted this a long time ago and switched
to a FeatureBitset with the current limit of 192 bits.
This patch completes transition to the bitset for feature bits extending
it to asm matcher and MC code emitter.
Differential Revision: https://reviews.llvm.org/D59002
llvm-svn: 355839
Includes a fix to emit a CheckOpcode for build_vector when immAllZerosV/immAllOnesV is used as a pattern root. This means it can't be used to look through bitcasts when used as a root, but that's probably ok. This extra CheckOpcode will ensure that the first match in the isel table will be a SwitchOpcode which is needed by the caching optimization in the ISel Matcher.
Original commit message:
Previously we had build_vector PatFrags that called ISD::isBuildVectorAllZeros/Ones. Internally the ISD::isBuildVectorAllZeros/Ones look through bitcasts, but we aren't able to take advantage of that in isel. Instead of we have to canonicalize the types of the all zeros/ones build_vectors and insert bitcasts. Then we have to pattern match those exact bitcasts.
By emitting specific matchers for these 2 nodes, we can make isel look through any bitcasts without needing to explicitly match them. We should also be able to remove the canonicalization to vXi32 from lowering, but I've left that for a follow up.
This removes something like 40,000 bytes from the X86 isel table.
Differential Revision: https://reviews.llvm.org/D58595
llvm-svn: 355784
The --force-interactive option was introduced in SVN 1.8, and trying to
pass it to older SVN clients causes an error; CentOS 7 includes SVN 1.7,
for example, so this makes `git llvm` not usable out of the box. Older
clients would be interactive by default anyway [1], so just don't pass
the option if it's not supported.
An alternative would be to check the version instead of checking the
help text, but I think directly detecting the presence of the option is
more direct.
[1] http://svn.apache.org/viewvc?view=revision&revision=1424037
Differential Revision: https://reviews.llvm.org/D59161
llvm-svn: 355782
Summary:
This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance.
In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable.
The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format:
Registers where the failure occurred (pc 0x0055555561b4):
x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025
x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001
x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000
x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000
x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078
x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000
x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000
x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4
... and prints after the dump of memory tags around the buggy address.
Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging.
Reviewers: pcc, eugenis
Reviewed By: pcc, eugenis
Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58857
llvm-svn: 355738
From the Python subprocess docs:
If shell is True, it is recommended to pass args as a string rather than as
a sequence.
[...]
If args is a sequence, the first item specifies the command string, and any
additional items will be treated as additional arguments to the shell itself.
Prior to this change, the `--version` would be passed to the shell, not to
a potential gn binary on $PATH, and running `gn` without any arguments makes
it exit with an exit code != 0, so the script would think that there wasn't
a working gn binary on $PATH.
Fix this by following the documentation's recommendation of using a string
now that we pass shell=True. I tested this on macOS and Windows, each with
the three cases of
- no gn on PATH (should run gn downloaded by get.py if present,
else suggest running get.py)
- broken gn wrapper on PATH (should behave like the previous item)
- working gn on PATH (should use gn on PATH)
llvm-svn: 355694
`os.uname()` doesn't exist on Windows, so use `platform.machine()` which
returns `os.uname()[4]` on non-Win and (on 64-bit systems) "AMD64" on Windows.
Also use `sys.platform` instead of `platform` to check for Windows-ness for the
file extension in gn.py (get.py got this right).
Differential Revision: https://reviews.llvm.org/D59115
llvm-svn: 355693
Use the system shell to see if we can find a 'gn' binary on $PATH. This solves the error wherein subprocess.call fails ungracefully if the binary doesn't exist.
llvm-svn: 355645
Summary:
ShadowCallStack on x86_64 suffered from the same racy security issues as
Return Flow Guard and had performance overhead as high as 13% depending
on the benchmark. x86_64 ShadowCallStack was always an experimental
feature and never shipped a runtime required to support it, as such
there are no expected downstream users.
Reviewers: pcc
Reviewed By: pcc
Subscribers: mgorny, javed.absar, hiraditya, jdoerfert, cfe-commits, #sanitizers, llvm-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D59034
llvm-svn: 355624
I had hoped we could remove the dependency on shell32.lib from lib/Support
(there isn't much depending on it), but looks like this will take a while. So
for now, port this over.
Differential Revision: https://reviews.llvm.org/D58925
llvm-svn: 355604
This caused the first matcher in the isel table for many targets to Opc_Scope instead of Opc_SwitchOpcode. This leads to a significant increase in isel match failures.
llvm-svn: 355433
These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once.
This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched.
Differential Revision: https://reviews.llvm.org/D58939
llvm-svn: 355431
The description for CPUs was just the CPU name wrapped with "Select the " and " processor". We can just do that directly in the help printer instead of making a separate version in the binary for each CPU.
Also remove the Value field that isn't needed and was always 0.
Differential Revision: https://reviews.llvm.org/D58938
llvm-svn: 355429
We can already update multiple files in each update call, this extends it to work with wildcards as well in the same way as update_mca_test_checks.py (to support shells that won't do this for us - windows command prompt etc.)
Differential Revision: https://reviews.llvm.org/D58817
llvm-svn: 355386
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
Apparently older versions of clang like 3.6 require an extra set of curly braces around std::array initializations. I'm told the C++ language was changed regarding this by CWG 1270.
llvm-svn: 355327
This build target is currently unused, but after r355144 the sync script
started complaining about cfi.cpp not being listed, and this makes the
script happy again.
llvm-svn: 355275
Previously we had build_vector PatFrags that called ISD::isBuildVectorAllZeros/Ones. Internally the ISD::isBuildVectorAllZeros/Ones look through bitcasts, but we aren't able to take advantage of that in isel. Instead of we have to canonicalize the types of the all zeros/ones build_vectors and insert bitcasts. Then we have to pattern match those exact bitcasts.
By emitting specific matchers for these 2 nodes, we can make isel look through any bitcasts without needing to explicitly match them. We should also be able to remove the canonicalization to vXi32 from lowering, but I've left that for a follow up.
This removes something like 40,000 bytes from the X86 isel table.
Differential Revision: https://reviews.llvm.org/D58595
llvm-svn: 355224
This lets us detect file size overflows when creating a 64-bit binary on
a 32-bit machine.
Differential Revision: https://reviews.llvm.org/D58840
llvm-svn: 355218
Subtarget features are stored in a std::bitset that has been subclassed. There is a special constructor to allow the tablegen files to provide a list of bits to initialize the std::bitset to. This constructor isn't constexpr and std::bitset doesn't support many constexpr operations either. This results in a static global constructor being used to initialize the feature bitsets in these files at startup.
To fix this I've introduced a new FeatureBitArray class that holds three 64-bit values representing the initial bit values and taught tablegen to emit hex constants for them based on the feature enum values. This makes the tablegen files less readable than they were before. I can add the list of features back as a comment if we think that's important.
I've added a method to convert from this class into the std::bitset subclass we had before. I considered making the new FeatureBitArray class just implement the std::bitset interface we need instead, but thought I'd see how others felts about that first.
I've simplified the interfaces to SetImpliedBits and ClearImpliedBits a little minimize the number of times we need to convert to the bitset.
This removes about 27K from my local release+asserts build of llc.
Differential Revision: https://reviews.llvm.org/D58520
llvm-svn: 355167
This enables lit to work with unicode file names via mkdir, rm, and redirection.
Lit still uses utf-8 internally, but converts to utf-16 on Windows, or just utf-8
bytes on everything else.
Committed on behalf of Jason Mittertreiner
Differential Revision: https://reviews.llvm.org/D56754
llvm-svn: 355122
Check that we do not crash if a parallelism group is explicitly set to
None. Permits usage of the following pattern.
[lit.common.cfg]
lit_config.parallelism_groups['my_group'] = None
if <condition>:
lit_config.parallelism_groups['my_group'] = 3
[project/lit.cfg]
config.parallelism_group = 'my_group'
Reviewers: rnk
Differential Revision: https://reviews.llvm.org/D58305
llvm-svn: 354912
The previous sort comparator was not deterministic, i.e. in some
situations it would be possible for lhs < rhs && rhs < lhs. This was
discovered by an STL assertion in a Windows debug build of llvm-tblgen.
Differential Revision: https://reviews.llvm.org/D58687
llvm-svn: 354910
The --disassembler-options, or -M, are used to customize
the disassembler and affect its output.
The two implemented options allow selecting register names on ARM:
* With -Mreg-names-raw, the disassembler uses rNN for all registers.
* With -Mreg-names-std it prints sp, lr and pc for r13, r14 and r15,
which is the default behavior of llvm-objdump.
Differential Revision: https://reviews.llvm.org/D57680
llvm-svn: 354870
More or less all the instructions defined in the v8.2a full-fp16
extension are defined as UNPREDICTABLE if you put them in an IT block
(Thumb) or use with any condition other than AL (ARM). LLVM didn't
know that, and was happy to conditionalise them.
In order to force these instructions to count as not predicable, I had
to make a small Tablegen change. The code generation back end mostly
decides if an instruction was predicable by looking for something it
can identify as a predicate operand; there's an isPredicable bit flag
that overrides that check in the positive direction, but nothing that
overrides it in the negative direction.
(I considered the alternative approach of actually removing the
predicate operand from those instructions, but thought that it would
be more painful overall for instructions differing only in data type
to have different shapes of operand list. This way, the only code that
has to notice the difference is the if-converter.)
So I've added an isUnpredicable bit alongside isPredicable, and set
that bit on the right subset of FP16 instructions, and also on the
VSEL, VMAXNM/VMINNM and VRINT[ANPM] families which should be
unpredicable for all data types.
I've included a couple of representative regression tests, both of
which previously caused an fp16 instruction to be conditionalised in
ARM state and (with -arm-no-restrict-it) to be put in an IT block in
Thumb.
Reviewers: SjoerdMeijer, t.p.northover, efriedma
Reviewed By: efriedma
Subscribers: jdoerfert, javed.absar, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57823
llvm-svn: 354768
OPC_CheckCondCode is always used as operand 2 of a setcc. And its always surrounded by a MoveChild2 and a MoveParent. By having a dedicated opcode for this case we can reduce the number of bytes needed for this pattern from 4 bytes to 2.
This saves ~3000 bytes in the X86 table.
llvm-svn: 354763
Summary:
This adds support for defining patterns for global isel using pointer
types, for example:
def : Pat<(load GPR32:$src),
(p1 (LOAD GPR32:$src))>;
DAGISelEmitter will ignore the pointer information and treat these
types as integers with the same bit-width as the pointer type.
Reviewers: dsanders, rtereshin, arsenm
Reviewed By: arsenm
Subscribers: Petar.Avramovic, wdng, rovka, kristof.beyls, jfb, volkan, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57065
llvm-svn: 354510
This class is used for two difference tablegen generated tables. For one of the tables the Value FeatureBitset only has one bit set. For the other usage the Implies field was unused.
This patch changes the Value field to just be an unsigned. For the usage that put a real vector in bitset, we now use the previously unused Implies field and leave the Value field unused instead.
This is good for a 16K reduction in the size of llc on my local build with all targets enabled.
llvm-svn: 354243
From the docs: `class LitTestCase(unittest.TestCase)`
LitTestCase is an adaptor for providing a 'unittest' compatible
interface to 'lit' tests so that we can run lit tests with standard
python test runners.
It does not seem to be used anywhere.
Differential Revision: https://reviews.llvm.org/D58264
llvm-svn: 354188
Move code that is executed on worker process to separate file. This
makes the use of the pickled arguments stored in global variables in the
worker a bit clearer. (Still not pretty though.)
Extract handling of parallelism groups to it's own function.
Use BoundedSemaphore instead of Semaphore. BoundedSemaphore raises for
unmatched release() calls.
Cleanup imports.
Differential Revision: https://reviews.llvm.org/D58196
llvm-svn: 354187
Summary:
Automatically upgrade debugging experience (single process, no thread
pool) when:
1) we only run a single test
2) user specifies `-j1`
Details:
Fix `--max-failures` in single process mode. Option did not have an
effect in single process mode.
Add display feedback for single process mode. Adapted test.
Improve argument checking (require positive integers).
`--single-process` is now essentially an alias for `-j1`. Should we
remove it?
Reviewers: rnk
Differential Revision: https://reviews.llvm.org/D58249
llvm-svn: 354068
This patch adds an `is_optimized` variable, orthogonal to `is_debug`, to allow for a gn analogue to `RelWithDebInfo` builds.
As part of this we'll want to explicitly enable GC+ICF, for the sake of `is_debug && is_optimized` builds. The flags normally default to true except that if you pass `/DEBUG` they default to false.
Differential Revision: https://reviews.llvm.org/D58075
llvm-svn: 353888
Summary:
While working on the GISel Combiner, I noticed I was producing location-less
error messages fairly often and set about fixing this. In the process, I
noticed quite a few places elsewhere in TableGen that also neglected to include
a relevant location.
This patch adds locations to errors that relate to a specific record (or a
field within it) and also have easy access to the relevant location. This is
particularly useful when multiclasses are involved as many of these errors
refer to the full name of a record and it's difficult to guess which substring
is grep-able.
Unfortunately, tablegen currently only supports Record granularity so it's not
currently possible to point at a specific Init so these sometimes point at the
record that caused the error rather than the precise origin of the error.
Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, nhaehnle
Reviewed By: nhaehnle
Subscribers: jdoerfert, nhaehnle, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58077
llvm-svn: 353862
This patch adds a -time-regions option to tablegen that can enable timers
(currently only one) that assess the performance of tablegen itself. This
can be useful for identifying scaling problems with tablegen backends.
This particular timer has allowed me to ignore time that is not attributed
the GISel combiner pass. It's useful by itself but it is particularly
useful in combination with https://reviews.llvm.org/D52954 which causes
this period of time to be annotated within Xcode Instruments which in turn
allows profile samples and recorded allocations attributed to reading
instructions to be filtered out.
llvm-svn: 353763
Allow the use of ninja instead of make. This is useful on some
platforms where we'd like to be able to limit the number of link jobs
without slowing down the other steps of the release.
This patch adds a -use-ninja command line option, which sets the
generator to Ninja both for LLVM and the test-suite. It also deals with
some differences between make and ninja:
* DESTDIR handling - ninja doesn't like this to be listed after the
target, but both make and ninja can handle it before the command
* Verbose mode - ninja uses -v, make uses VERBOSE=1
* Keep going mode - make has a -k mode, which builds as much as possible
even when failures are encountered; for ninja we need to set a hard
limit (we use 100 since most people won't look at 100 failures anyway)
I haven't tested with gmake.
llvm-svn: 353685
If we run into a pattern that looks like this:
add
(complex $x, $y)
(complex $x, $z)
We should skip the pattern instead of asserting/doing something unpredictable.
This makes us return an Error in that case, and adds a testcase for skipped
patterns.
Differential Revision: https://reviews.llvm.org/D57980
llvm-svn: 353586
This patch accompanies the RFC posted here:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
This patch adds a new CallBr IR instruction to support asm-goto
inline assembly like gcc as used by the linux kernel. This
instruction is both a call instruction and a terminator
instruction with multiple successors. Only inline assembly
usage is supported today.
This also adds a new INLINEASM_BR opcode to SelectionDAG and
MachineIR to represent an INLINEASM block that is also
considered a terminator instruction.
There will likely be more bug fixes and optimizations to follow
this, but we felt it had reached a point where we would like to
switch to an incremental development model.
Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii
Differential Revision: https://reviews.llvm.org/D53765
llvm-svn: 353563
Mostly achieved by assuming that anything that isn't Win or Mac is ELF,
which seems reasonable enough for now.
Differential Revision: https://reviews.llvm.org/D57870
llvm-svn: 353470
As far as I can tell, malloc.h is only being used here to provide
a definition of mallinfo (malloc itself is declared in stdlib.h via
cstdlib). We already have a macro for whether mallinfo is available,
so switch to using that instead.
Differential Revision: https://reviews.llvm.org/D57807
llvm-svn: 353329
Not depending on //clang/lib/StaticAnalyzer/Core and
//clang/lib/StaticAnalyzer/Frontend causes a linker error even if
ClangSACheckers are not supported.
Undefined symbols for architecture x86_64:
"clang::ento::CreateAnalysisConsumer(clang::CompilerInstance&)", referenced from:
clang::tidy::ClangTidyASTConsumerFactory::CreateASTConsumer(
clang::CompilerInstance&, llvm::StringRef)
in libclangTidy.a(libclangTidy.ClangTidy.o)
Patch from Mirko Bonadei <mbonadei@webrtc.org>!
Differential Revision: https://reviews.llvm.org/D57777
llvm-svn: 353244
Summary:
While the backend code of FileCheck relies on definition of variable
from the command-line to have an equal sign '=' and a variable name
before that, the frontend does not actually enforce it. This leads to
FileCheck crashing when invoked with invalid syntax for the -D option.
This patch adds the missing validation in the frontend. It also makes
the -D option an AlwaysPrefix option to be able to detect -D=FOO as
being a define without variable and -D as missing its value.
Copyright:
- Linaro (changes in version 2 of revision D55940)
- GraphCore (changes in later versions)
Reviewers: jdenny
Subscribers: JonChesterfield, hiraditya, kristina, probinson,
llvm-commits
Differential Revision: https://reviews.llvm.org/D55940
llvm-svn: 353173
Trivial fix: decode was not called for all subprocess.check_output calls.
Commited on behalf of Andrew Boyarshin
Differential Revision: https://reviews.llvm.org/D57505
llvm-svn: 353168
NDK r19 includes a sysroot that can be used directly by the compiler
without creating a standalone toolchain, so we just need a handful
of flags to point Clang there.
Differential Revision: https://reviews.llvm.org/D57733
llvm-svn: 353139
Summary:
There are a few instructions that all map to the same opcode, so
when disassembling, we have to pick one. That was just the first one
before (the except_ref variant in the case of "call"), now it is the
one marked as IsCanonical in tablegen, or failing that, the shortest
name (which is typically the "canonical" one).
Also introduced a canonical "end" instruction for this purpose.
Reviewers: dschuff, tlively
Subscribers: sbc100, jgravelle-google, aheejin, llvm-commits, sunfish
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57713
llvm-svn: 353131
The current build was producing names like llvm-undname.exe.pdb, which looks unusual to me at least. This switches them to the more common llvm-undname.pdb style.
Differential Revision: https://reviews.llvm.org/D57613
llvm-svn: 353099
The current build was producing names like llvm-undname.exe.pdb, which looks unusual to me at least. This switches them to the more common llvm-undname.pdb style.
Differential Revision: https://reviews.llvm.org/D57613
llvm-svn: 353094
Without /DEBUG, the /Zi doesn't on its own create PDB files.
And since ninja runs multiple compilations in parallel, we need /FS to prevent contention on PDBs.
Differential Revision: https://reviews.llvm.org/D57612
llvm-svn: 353093
LLVM_ENABLE_DAGISEL_COV can be used to instrument DAGISel tablegen
selection code to show which patterns along with Complex patterns were
used when selecting instructions. Unfortunately this is turned off by
default and was broken but never tested.
This required a simple fix (missing new line) to get it to build again.
llvm-svn: 353091
We'll need to do this eventually if we create an installable package.
For now, this lets me use the archives to build Android, whose build
system wants to copy the archives to another location.
Differential Revision: https://reviews.llvm.org/D57607
llvm-svn: 352907
check-llvm already listed llvm-lit as script which counts as a dep, so running
check-llvm worked fine, but `ninja -C out/gn llvm/test` didn't build llvm-lit
before if it wasn't already there.
llvm-svn: 352893
LLVMConfig.with_environment() uses os.path.normcase(os.path.normpath(x)) to
normalize temporary env vars. LLVMConfig.use_clang() uses with_environment() to
temporarily set PATH and then look for clang there. This means that on Windows,
clang will be run with a path like c:\foo\bin\clang.EXE (with a lower-case
"C:").
lit.util.which() used to not do this, which means the executables added in
clang/test/lit.cfg.py (e.g. c-index-test) were run with a path like
C:\foo\bin\c-index-test.EXE (because both CMake and GN happen to write
clang_tools_dir with an upper-case C to lit.site.cfg.py).
clang/test/Index/pch-from-libclang.c requires that both c-index-test and clang
use _exactly_ the same resource dir path (same case and everything), because a
hash of the resource directory is used as module cache path.
This patch is necessary but not sufficient to make pch-from-libclang.c pass on
Windows.
Differential Revision: https://reviews.llvm.org/D57343
llvm-svn: 352704
This fixes a "bytes-like object is required, not 'str'" python3 error I hit on update_llc_test_checks.py (but present on the other scripts as well) by matching what update_mca_test_checks.py already does, plus I've added an explicit 'utf-8' encoding.
llvm-svn: 352633
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
They were breaking the Windows build when using MSBuild, see the
discussion on D56781.
r351833: "Use response file when generating LLVM-C.dll"
> Use response file when generating LLVM-C.dll
>
> As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me.
>
> Commited on behalf of Jakob Bornecrantz
>
> Differential Revision: https://reviews.llvm.org/D56781
r352250: "Build LLVM-C.dll by default on windows and enable in release package"
> Build LLVM-C.dll by default on windows and enable in release package
>
> With the fixes to the building of LLVM-C.dll in D56781 this should now
> be safe to land. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 352492
Prebuilts are available for x86_64 Linux, macOS, Windows. The script always
pulls the latest GN version.
Differential Revision: https://reviews.llvm.org/D57256
llvm-svn: 352420
Fixes a minor regression from r351248.
While here, also make it possible to opt out of lld by saying
use_lld=false when clang_base_path is set. (use_lld still defaults to
true if clang_base_path is set.)
llvm-svn: 352415
With the fixes to the building of LLVM-C.dll in D56781 this should now
be safe to land. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 352250
- gcc doesn't understand -Wstring-conversion, so pass that only to clang
- disable a few gcc warnings that are noisy and also disabled in the cmake build
- -Wstrict-aliasing pointed out that the cmake build builds clang with
-fno-strict-aliasing, so do that too
Differential Revision: https://reviews.llvm.org/D57191
llvm-svn: 352141
This patch replaces the existing LLVMVectorSameWidth matcher with LLVMScalarOrSameVectorWidth.
The matching args must be either scalars or vectors with the same number of elements, but in either case the scalar/element type can differ, specified by LLVMScalarOrSameVectorWidth.
I've updated the _overflow intrinsics to demonstrate this - allowing it to return a i1 or <N x i1> overflow result, matching the scalar/vectorwidth of the other (add/sub/mul) result type.
The masked load/store/gather/scatter intrinsics have also been updated to use this, although as we specify the reference type to be llvm_anyvector_ty we guarantee the mask will be <N x i1> so no change in behaviour
Differential Revision: https://reviews.llvm.org/D57090
llvm-svn: 351957
The old diagnostic form of the trace produced by -v and -vv looks
like:
```
check1:1:8: remark: CHECK: expected string found in input
CHECK: abc
^
<stdin>:1:3: note: found here
; abc def
^~~
```
When dumping annotated input is requested (via -dump-input), I find
that this old trace is not useful and is sometimes harmful:
1. The old trace is mostly redundant because the same basic
information also appears in the input dump's annotations.
2. The old trace buries any error diagnostic between it and the input
dump, but I find it useful to see any error diagnostic up front.
3. FILECHECK_OPTS=-dump-input=fail requests annotated input dumps only
for failed FileCheck calls. However, I have to also add -v or -vv
to get a full set of annotations, and that can produce massive
output from all FileCheck calls in all tests. That's a real
problem when I run this in the IDE I use, which grinds to a halt as
it tries to capture all that output.
When -dump-input=fail|always, this patch suppresses the old trace from
-v or -vv. Error diagnostics still print as usual. If you want the
old trace, perhaps to see variable expansions, you can set
-dump-input=none (the default).
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D55825
llvm-svn: 351881
This is a remnant from before the gn build had a working config.h.
Defining LLVM_LIBXML2_ENABLED only for targets that depend on build/libs/xml is
nice in that only some of the codebase needs to be rebuilt when
llvm_enable_libxml2 changes -- but config.h already defines it and defining it
there and then redundantly a second time for some targets is worse than having
it just in config.h.
No behavior change.
Differential Revision: https://reviews.llvm.org/D56908
llvm-svn: 351758
Since these are intended to be short and succinct, I've used the SPDX
full name. It's human readable, but formally agreed upon and will be
part of the SPDX spec for licenses.
llvm-svn: 351649
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
Right now we include ${TGT}GenCallingConv.inc once per each instruction
selection method implemented by ${TGT}:
- ${TGT}ISelLowering.cpp
- ${TGT}CallLowering.cpp
- ${TGT}FastISel.cpp
Instead, add a mechanism to tablegen for marking a particular convention
as "External", which causes tablegen to emit into the ::llvm namespace,
instead of as a static helper. This allows us to provide a header to
forward declare it, so we can simply call the function from all the
places it is referenced. Typically the calling convention analyzer is
called indirectly, so it doesn't benefit from inlining.
This saves a bit of final binary size, but mostly just saves object file
size:
before after diff artifact
12852K 12492K -360K X86ISelLowering.cpp.obj
4640K 4280K -360K X86FastISel.cpp.obj
1704K 2092K +388K X86CallingConv.cpp.obj
52448K 52336K -112K llc.exe
I didn't collect before numbers for X86CallLowering.cpp.obj, which is
for GlobalISel, but we should save 360K there as well.
This patch applies the strategy to the X86 backend, but there is no
reason it couldn't be applied to the other backends that implement
multiple ISel strategies, like AArch64.
Reviewers: craig.topper, hfinkel, efriedma
Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D56883
llvm-svn: 351616
r291284 added a nice mechanism to consistently pass CMake on/off toggles to
lit. This change uses it for LLVM_LIBXML2_ENABLED too (which was added around
the same time and doesn't use the new system yet).
Also alphabetically sort the list passed to llvm_canonicalize_cmake_booleans()
in llvm/test/CMakeLists.txt.
No intended behavior change.
Differential Revision: https://reviews.llvm.org/D56912
llvm-svn: 351615
Summary:
The operators simply print the underlying value or "None".
The trickier part of this patch is making sure the streaming operators
work even in unit tests (which was my primary motivation, though I can
also see them being useful elsewhere). Since the stream operator was a
template, implicit conversions did not kick in, and our gtest glue code
was explicitly introducing an implicit conversion to make sure other
implicit conversions do not kick in :P. I resolve that by specializing
llvm_gtest::StreamSwitch for llvm:Optional<T>.
Reviewers: sammccall, dblaikie
Reviewed By: sammccall
Subscribers: mgorny, dexonsmith, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D56795
llvm-svn: 351548
The check-hwasan build files assert that current_os == "linux" || current_os ==
"android", so pull it in only there.
ar is unused on mac, so don't set it in the stage2 toolchain. (It'd be nicer to
use llvm-libtool on mac instead of host libtool, but llvm-libtool doesn't seem
to understand the -no_warning_for_no_symbols flag.)
Differential Revision: https://reviews.llvm.org/D56898
llvm-svn: 351519
llvm/tools sets LLVM_TOOL_LTO_BUILD to Off if LLVM_ENABLE_PIC=OFF, but that's
not visible in llvm/test.
r289662 added the llvm_tool_lto_build lit parameter, there the intent was to
use it with an explicit -DLLVM_TOOL_LTO_BUILD=OFF, which is visible globally.
On the review for that (D27739), a mild preference was expressed for using a
lit parameter over checking the existence of libLTO.dylib. Since that works
with the LLVM_ENABLE_PIC=OFF case too and since it matches what we do for the
gold plugin, switch to that approach.
Differential Revision: https://reviews.llvm.org/D56805
llvm-svn: 351515
This broke the build, ending up with too long command-lines when invoking gen-mscv-exports.py.
> As it says in the subject, should have gone long enough now that this
> should be safe. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 351329
As it says in the subject, should have gone long enough now that this
should be safe. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 351324
The Android sanitizer tests are currently some of the most difficult
to run correctly, requiring at least 3 build directories which have
to be configured in just the right way and built in the correct order
(see e.g. [1] and the functions that it calls).
This patch adds a check-hwasan target which greatly simplifies running
the hwasan tests for gn users, taking advantage of its support for
multiple toolchains. With this the tests can be run simply by setting
an NDK path and running "ninja check-hwasan" with a compatible Android
device connected. The Linux/x86_64 and Android/aarch64 targets are
tested in parallel.
[1] https://github.com/llvm/llvm-zorg/blob/master/zorg/buildbot/builders/sanitizers/buildbot_android.sh
Differential Revision: https://reviews.llvm.org/D56713
llvm-svn: 351277
The path to the resource directory will end up being used in several
more places once the support for running check-hwasan lands. This
moves the definition to a central location so that it can be used
from those places.
Differential Revision: https://reviews.llvm.org/D56700
llvm-svn: 351255
While here, add a use_lld flag and default it to true when using
clang on non-mac.
Differential Revision: https://reviews.llvm.org/D56710
llvm-svn: 351248
Peter Collingbourne