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
This makes e.g. ToolChain::isCrossCompiling() in
clang/lib/Driver/ToolChain.cpp return the correct result
if the compiler was cross-compiled. This change also affects
llvm_default_target_triple, so cross-compiled compilers default to
targeting the cross-compilation target, which makes more sense than
the host that the compiler was compiled on.
This change will also be necessary in order for the correct triples
to appear in generated lit files for non-native targets.
Differential Revision: https://reviews.llvm.org/D56696
llvm-svn: 351168
Add an asm tool (will be required for building sanitizer_common on
x64) and set a soname for DSOs so that anything that links against
them gets the correct DT_NEEDED.
Differential Revision: https://reviews.llvm.org/D56705
llvm-svn: 351167
Some of the sanitizer runtime code needs to be built with RTTI;
this allows that code to opt in to RTTI.
Differential Revision: https://reviews.llvm.org/D56627
llvm-svn: 351155
This is needed because otherwise if source dir is at location whose path
contains non-ASCII character then python will complain about
SyntaxError.
SyntaxError: Non-ASCII character '\xc4' in file
/home/D?vis/libc++/src/build/bin/llvm-lit on line 16, but no encoding
declared; see http://python.org/dev/peps/pep-0263/ for details
Patch by davispuh
Differential Revision: https://reviews.llvm.org/D50201
llvm-svn: 351113
Since people weren't enthused about moving the .gn file to the toplevel in
D56419, here's a script to make gn at least somewhat more pleasant to invoke
(useful for gn clean, gn args --list, gn desc, etc).
Differential Revision: https://reviews.llvm.org/D56565
llvm-svn: 351064
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: 351039
This shortcut mechanism for creating types was added 10 years ago, but
has seen almost no uptake since then, neither internally nor in
external projects.
The very small number of characters saved by using it does not seem
worth the mental overhead of an additional type-creation API, so,
delete it.
Differential Revision: https://reviews.llvm.org/D56573
llvm-svn: 351020
I didn't break all that much during upstreaming, just needs two small fixes:
- fix spelling of MCJITTests.def file
- make libLTO a shared_library to put it in bin/ on Windows where it is in the
CMake build too
Differential Revision: https://reviews.llvm.org/D56630
llvm-svn: 351004
This makes it possible to build llvm-symbolizer for Android, which
is one of the prerequisites for running the sanitizer tests on Android.
Differential Revision: https://reviews.llvm.org/D56577
llvm-svn: 350979
Also change the toolchain description to use current_os instead of
host_os so that the template can be used for cross builds, and add
a current_os to the win toolchain to match the unix toolchain.
Differential Revision: https://reviews.llvm.org/D56576
llvm-svn: 350977
This makes the generated files go to the right place when using a non-default toolchain.
Differential Revision: https://reviews.llvm.org/D56427
llvm-svn: 350963
Most significantly, this makes bin/llvm-lit executable so that it
can be run in the usual way.
Differential Revision: https://reviews.llvm.org/D56423
llvm-svn: 350688
Convert the output of "git rev-parse --short HEAD" to a string before
substituting it into the output file. Without this the output file
will look like this on Python 3:
#define LLVM_REVISION "git-b'6a4895a025f'"
Differential Revision: https://reviews.llvm.org/D56459
llvm-svn: 350686
The PowerPC target itself is similar to the X86 target in https://reviews.llvm.org/rL348903
The llvm-exegesis unittests bits are similar to the corresponding AArch64 in https://reviews.llvm.org/rL350499
The whole patch is very similar to the WebAssembly target being added in https://reviews.llvm.org/rL350628
Also add a dep from tools/llvm-exegesis/lib to the AArch64 subdir, which I
failed to do in r350499.
The motivation for this target is solely that it has a unit test and I want to
enable the GN<->CMake unittest syncing check for llvm.
Differential Revision: https://reviews.llvm.org/D56416
llvm-svn: 350629
The WebAssembly target itself is similar to the X86 target in https://reviews.llvm.org/rL348903
The unittests bits are similar to the corresponding AArch64 in https://reviews.llvm.org/rL350499
The motivation for this target is solely that it has a unit test and I want to
enable the GN<->CMake unittest syncing check for llvm. (After this, only the
PowerPC target is needed and I can turn it on.)
Differential Revision: https://reviews.llvm.org/D56374
llvm-svn: 350628
The -o flag means something different to ar than what appears to be
intended here. Also, llvm-ar doesn't accept the flag in this position.
Differential Revision: https://reviews.llvm.org/D56426
llvm-svn: 350604
If a user has PYTHONPATH set in the environment, append new entries to
it rather than blindly setting PYTHONPATH to a fixed string. This
allows tests to, for example, find psutil if it is in
PYTHONPATH. Without this change, lit will detect psutil but then
various tests will fail because PYTHONPATH has been overwritten and
psutil cannot be found.
llvm-svn: 350536
Add a "deref" view that displays the pointed to objects since
other visualizers often need to display data reference by internal
PointerUnions
llvm-svn: 350469
This is slightly ugly for three reasons:
- The shlib needs to go next to the binary to be found on all platforms, so the
build files refer to target_out_dir
- The explicit -fPIC flag needed on the shared lib side, and the -rdynamic flag
needed on the host side, on Linux
- Plugins that refer to LLVM code and assume that the host will resolve them
don't work on Windows -- PluginsTests won't test anything on Windows (but
DynamicLibraryTests will, since the dll here doesn't call LLVM code)
If we get lots more of these plugin / plugin host targets it might make sense
to add a template for them. But for now, these are the last ones we need.
(We're at 6 plugin hosts, 2 of them tests, and at 6 shared libraries, 2 of them
tests as well. clang is a plugin host by default in the CMake build but not
(yet?) in the GN build.)
Differential Revision: https://reviews.llvm.org/D56330
llvm-svn: 350454
I'm pretty unhappy this patch: DebugInfoPDBTests uses an API that requires some
magic txt file to be next to the unit test executable that stores the absolute
path to the LLVM source root.
The choices here are:
1. Don't use the unittest() template for DebugInfoPDBTests and set output_dir
for unit tests in two places (the gni file for every test but this one, and the
BUILD.gn file for this specific test).
2. Add another unittest_foo() template variation for this one test.
I went with the former, and added a comment to the template to look out for
this.
(The CMake build has the same issue.)
Differential Revision: https://reviews.llvm.org/D56324
llvm-svn: 350447
Adds build files for //llvm/unittest/[A-D].
Also teach sync_source_lists_from_cmake.py to not complain about missing
BUILD.gn files for CMakeLists.txt files that just call add_subdirectory()
without calling add_.+_unittest, like e.g.
llvm/unittests/Target/CMakeLists.txt.
(Omits CodeGen/GlobalISel and DebugInfo/PDB because their build files are somewhat interesting, and this patch is already on the larger side.)
Differential Revision: https://reviews.llvm.org/D56212
llvm-svn: 350411
With this, check-llvm runs and passes all of clang's lit tests. It doesn't run
any of its unit tests yet.
This is the only change in the GN build patch series that needs a change to a
file outside of llvm/utils/gn: llvm/test/tools/llvm-config/booleans.test checks
the result of llvm-config --build-system for some reason, so I'm updating the
test to accept "gn" as valid output in addition to "cmake". (The alternative
would be to let the gn build self-identify as cmake, which seems worse.)
Like with check-clang and check-lld, running just ninja -C out/gn will build
all prerequisites needed to run tests, but it won't run the tests (so that the
build becomes clean after one build). Running ninja -C out/gn check-llvm will
build prerequisites if needed and run the tests. The check-llvm target never
becomes clean and runs tests every time.
Differential Revision: https://reviews.llvm.org/D56195
llvm-svn: 350410
Not used by anything yet, but will be needed to make check-llvm run ld64's libLTO plugin tests.
Differential Revision: https://reviews.llvm.org/D56317
llvm-svn: 350409
Nothing pulls them in yet, but they will be needed for check-llvm.
LineEditor depends on libedit, so create a gn/build/lib for it, following the
usual pattern.
Differential Revision: https://reviews.llvm.org/D56316
llvm-svn: 350407
Summary:
The previously introduced new operand type for br_table didn't have
a disassembler implementation, causing an assert.
Reviewers: dschuff, aheejin
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D56227
llvm-svn: 350366
Hans Wennborg