See http://lists.llvm.org/pipermail/llvm-dev/2017-June/113975.html for a related previous discussion.
Many tools install signal handlers to print stack traces and optionally
symbolize the addresses with an external program 'llvm-symbolizer' (when
searching for 'llvm-symbolizer', the directory containg the executable
is preferred over PATH).
'llvm-symbolizer' can be slow if the executable is large and/or if
llvm-symbolizer' itself is under-optimized. For example, my 'llvm-lto2' from a
-DCMAKE_BUILD_TYPE=Debug build is 443MiB. The 'llvm-symbolizer' from the same
build takes ~2s to symbolize it. (An optimized 'llvm-symbolizer' takes 0.34s).
A crashed clang may take more than 5s to symbolize a stack trace.
If a test file has several `not --crash` RUN lines. It can be very slow in a Debug build.
This patch makes `not --crash` set an environment variable to suppress symbolization.
This is similar to D33804 which uses a command line option.
I pick 'symbolization' instead of 'symbolication' because the former is
used much more commonly and its stem matches 'llvm-symbolizer'.
Also set LLVM_DISABLE_CRASH_REPORT=1, which is currently only applicable on
`__APPLE__`.
Reviewed By: dblaikie, aganea
Differential Revision: https://reviews.llvm.org/D86170
This commit introduced a non-trivial compile time regression that needs
to be addressed: https://reviews.llvm.org/D70365#2227627
Given that it is unclear how long that will take, I'll revert it for
now.
This reverts commit eedf18fc1f5fc71bb896204abf41fc5a2dbf25f7.
Intrinsic properties can now be set to default and applied to all
intrinsics. If the attributes are not needed, the user can opt-out by
setting the DisableDefaultAttributes flag to true.
Differential Revision: https://reviews.llvm.org/D70365
Regarding this bug in Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=46451
I went ahead and fixed the regexp pattern and now Python script is able
to extract vplan graphs from the log files. Additionally some test for
this would be nice to have but I'm not sure are Python scripts tested
in LLVM and if so where they live.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D86068
This patch fixes a bug which skipped
adding predicate matcher for a pattern in many cases.
For example, if predicate is Load and
its memoryVT is non-null then the loop
continues and never reaches to the end which
adds the predicate matcher. This patch moves the
matcher addition to the top of the loop
so that it gets added regardless of contextual checks
later in the loop.
Other way to fix this issue is to remove all "continue" statements
in checks and let the loop continue till end.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D83034
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Differential revision: https://reviews.llvm.org/D85820
Use the TableGen directive back-end to generate code for the clauses unparsing.
Reviewed By: sscalpone, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D85851
This patch implements initial backend support for a -mtune CPU controlled by a "tune-cpu" function attribute. If the attribute is not present X86 will use the resolved CPU from target-cpu attribute or command line.
This patch adds MC layer support a tune CPU. Each CPU now has two sets of features stored in their GenSubtargetInfo.inc tables . These features lists are passed separately to the Processor and ProcessorModel classes in tablegen. The tune list defaults to an empty list to avoid changes to non-X86. This annoyingly increases the size of static tables on all target as we now store 24 more bytes per CPU. I haven't quantified the overall impact, but I can if we're concerned.
One new test is added to X86 to show a few tuning features with mismatched tune-cpu and target-cpu/target-feature attributes to demonstrate independent control. Another new test is added to demonstrate that the scheduler model follows the tune CPU.
I have not added a -mtune to llc/opt or MC layer command line yet. With no attributes we'll just use the -mcpu for both. MC layer tools will always follow the normal CPU for tuning.
Differential Revision: https://reviews.llvm.org/D85165
The assembly parser "canonicalizes" the mnemonics it processes at an
early level by making them lowercase. The goal of this is presumably to
allow assembly to be case-insensitive. However, if one declares an
instruction with a mnemonic using uppercase letters, then it will
never get matched, since the generated lookup tables for the
AsmMatcherEmitter didn't lower() their inputs. This made it difficult to
have instructions that get printed using a mnemonic that includes
uppercase letters, since they could not be parsed.
To fix this problem, this patch adds a few calls to lower() to make the
lookup tables used in AsmMatcherEmitter be case-insensitive. This allows
instruction mnemonics with uppercase letters to be parsed.
Differential Revision: https://reviews.llvm.org/D85858
These should really match either G_BUILD_VECTOR or
G_BUILD_VECTOR_TRUNC, but there doesn't seem to be an existing
mechanism for matching alternative opcodes. There is GIM_SwitchOpcode,
but it seems to assume it's oly only used for matcher optimization.
I could also omit any opcode check and rely on the matcher directly
checking the opcode, but the table optimizer currently assumes there
has to be an opcode check.
Also doesn't try to handle undef elements like the DAG version.
`clang` currently requires the native linker on Solaris:
- It passes `-C` to `ld` which GNU `ld` doesn't understand.
- To use `gld`, one needs to pass the correct `-m EMU` option to select
the right emulation. Solaris `ld` cannot handle that option.
So far I've worked around this by passing `-DCLANG_DEFAULT_LINKER=/usr/bin/ld`
to `cmake`. However, if someone forgets this, it depends on the user's
`PATH` whether or not `clang` finds the correct linker, which doesn't make
for a good user experience.
While it would be nice to detect the linker flavor at runtime, this is more
involved. Instead, this patch defaults to `/usr/bin/ld` on Solaris. This
doesn't work on its own, however: a link fails with
clang-12: error: unable to execute command: Executable "x86_64-pc-solaris2.11-/usr/bin/ld" doesn't exist!
I avoid this by leaving absolute paths alone in `ToolChain::GetLinkerPath`.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D84029
This patch adds the translation of the proc_bind clause in a
parallel operation.
The values that can be specified for the proc_bind clause are
specified in the OMP.td tablegen file in the llvm/Frontend/OpenMP
directory. From this single source of truth enumeration for
proc_bind is generated in llvm and mlir (used in specification of
the parallel Operation in the OpenMP dialect). A function to return
the enum value from the string representation is also generated.
A new header file (DirectiveEmitter.h) containing definitions of
classes directive, clause, clauseval etc is created so that it can
be used in mlir as well.
Reviewers: clementval, jdoerfert, DavidTruby
Differential Revision: https://reviews.llvm.org/D84347
With this patch we will match most *uses* of "temporary" named things in
the IR via regular expressions, not their name at creation time. The new
"values" we match are:
- "unnamed" globals: `@[0-9]+`
- debug metadata: `!dbg ![0-9]+`
- loop metadata: `!loop ![0-9]+`
- tbaa metadata: `!tbaa ![0-9]+`
- range metadata: `!range ![0-9]+`
- generic metadata: `metadata ![0-9]+`
- attributes groups: `#[0-9]`
We still don't match the declarations but that can be done later. This
patch can introduce churn when existing check lines contain the old
hardcoded versions of the above "values". We can add a flag to opt-out,
or opt-in, if necessary.
Reviewed By: arichardson, MaskRay
Differential Revision: https://reviews.llvm.org/D85099
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This patch takes advantage of the directive information and tablegen generation
to replace the clauses class parse tree and in the dump parse tree sections.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D85549
ISD::ATOMIC_STORE arbitrarily has the operands in the opposite order
from regular ISD::STORE, which always introduced an annoying
duplication of patterns to handle both cases. Since in GlobalISel
there's just the one G_STORE, we need to swap the operands to
correctly emit the type check for the pointer operand.
Some work started in 20aafa31569b5157e792daa8860d71dd0df8a53a to
migrate SelectionDAG to use ISD::STORE for atomics, but that work
seems to have stalled. Since this is the pretty much the last
operation which matters which isn't supported for AMDGPU, use this
compatibility hack to unblock declaring it functionally complete.
Not sure what's going on with the pending_phis AArch64 test. It seems
it didn't always use atomics, and I'm not sure what it was originally
testing matters anymore.
This patch takes advantage of the directive information and tablegen generation
to replace the clauses class parse tree and in the dump parse tree sections.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D85549
These definitions are needed by any file which uses gtest. Previously we
were adding them in the add_unittest function, but over time we've
accumulated libraries (which don't go through add_unittest) building on
gtest and this has resulted in proliferation of the definitions.
Making this a part of the library interface enables them to be managed
centrally. This follows a patch for -Wno-suggest-override (D84554) which
took a similar approach.
Differential Revision: https://reviews.llvm.org/D84748
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Add a small script to sum *.stats file given as input and output the totals
usage example:
merge-stats.py $(find ./builddir/ -name "*.stats") > total.stats
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D83505
As of GN 3028c6a426a4, the hack that transformed "libs" ending in
".framework" from -l arguments to -framework arguments has been removed.
Instead, "frameworks" must be used, and the toolchain must provide
support.
Differential Revision: https://reviews.llvm.org/D84219
