Summary:
In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX
(ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html),
this patch adds customizations to the CMake files in order to properly
invoke the host toolchain for the build on AIX.
Additional changes to enable a successful build will follow.
Patch by Xing Xue
Reviewers: hubert.reinterpretcast, jasonliu, sfertile
Reviewed by: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D58250
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356104 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instruments is a useful tool for finding performance issues in LLVM but it can
be difficult to identify regions of interest on the timeline that we can use
to filter the profiler or allocations instrument. Xcode 10 and the latest
macOS/iOS/etc. added support for the os_signpost() API which allows us to
annotate the timeline with information that's meaningful to LLVM.
This patch causes timer start and end events to emit signposts. When used with
-time-passes, this causes the passes to be annotated on the Instruments timeline.
In addition to visually showing the duration of passes on the timeline, it also
allows us to filter the profile and allocations instrument down to an individual
pass allowing us to find the issues within that pass without being drowned out
by the noise from other parts of the compiler.
Using this in conjunction with the Time Profiler (in high frequency mode) and
the Allocations instrument is how I found the SparseBitVector that should have
been a BitVector and the DenseMap that could be replaced by a sorted vector a
couple months ago. I added NamedRegionTimers to TableGen and used the resulting
annotations to identify the slow portions of the Register Info Emitter. Some of
these were placed according to educated guesses while others were placed
according to hot functions from a previous profile. From there I filtered the
profile to a slow portion and the aforementioned issues stood out in the
profile.
To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the
compiler under Instruments with -time-passes like so:
instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll'
Then open the resulting trace in Instruments.
There was a talk at WWDC 2018 that explained the feature which can be found at
https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know
more about it.
Reviewers: bogner
Reviewed By: bogner
Subscribers: jdoerfert, mgorny, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D52954
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354365 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353329 91177308-0d34-0410-b5e6-96231b3b80d8
llvm::is_trivially_copyable portability is verified at compile time using
std::is_trivially_copyable as the reference implementation.
Unfortunately, the latter is not available on all platforms, so introduce
a proper configure check to detect if it is available on the target platform.
In a similar manner, std::is_copy_assignable is not fully supported for gcc4.9.
Provide a portable (?) implementation instead.
Differential Revision: https://reviews.llvm.org/D57018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351820 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
getLastAccessedTime() and getLastModificationTime() provided times in nanoseconds but with only 1 second resolution, even when the underlying file system could provide more precise times than that.
These changes add sub-second precision for unix platforms that support improved precision.
Also add some comments to make sure people are aware that the resolution of times can vary across different file systems.
Reviewers: labath, zturner, aaron.ballman, kristina
Reviewed By: aaron.ballman, kristina
Subscribers: lebedev.ri, mgorny, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D54826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347530 91177308-0d34-0410-b5e6-96231b3b80d8
Since crash dumping landed in r268519, May 2016, I have not once seen
anyone use an uploaded minidump to debug a compiler crash. Therefore,
I'm turning this off by default. The dumps clutter up user and buildbot
temp directories. Each file is only about 56KB, but it adds up.
In the context of clang, the extra line about the minidump confuses
users, when what we really want from them is the pre-processed source
code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340185 91177308-0d34-0410-b5e6-96231b3b80d8
This new JIT event listener supports generating profiling data for
the linux 'perf' profiling tool, allowing it to generate function and
instruction level profiles.
Currently this functionality is not enabled by default, but must be
enabled with LLVM_USE_PERF=yes. Given that the listener has no
dependencies, it might be sensible to enable by default once the
initial issues have been shaken out.
I followed existing precedent in registering the listener by default
in lli. Should there be a decision to enable this by default on linux,
that should probably be changed.
Please note that until https://reviews.llvm.org/D47343 is resolved,
using this functionality with mcjit rather than orcjit will not
reliably work.
Disregarding the previous comment, here's an example:
$ cat /tmp/expensive_loop.c
bool stupid_isprime(uint64_t num)
{
if (num == 2)
return true;
if (num < 1 || num % 2 == 0)
return false;
for(uint64_t i = 3; i < num / 2; i+= 2) {
if (num % i == 0)
return false;
}
return true;
}
int main(int argc, char **argv)
{
int numprimes = 0;
for (uint64_t num = argc; num < 100000; num++)
{
if (stupid_isprime(num))
numprimes++;
}
return numprimes;
}
$ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o
/tmp/expensive_loop.ll
$ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1
$ perf inject --jit -i perf.data -o perf.jit.data
$ perf report -i perf.jit.data
- 92.59% lli jitted-5881-2.so [.] stupid_isprime
stupid_isprime
main
llvm::MCJIT::runFunction
llvm::ExecutionEngine::runFunctionAsMain
main
__libc_start_main
0x4bf6258d4c544155
+ 0.85% lli ld-2.27.so [.] do_lookup_x
And line-level annotations also work:
│ for(uint64_t i = 3; i < num / 2; i+= 2) {
│1 30: movq $0x3,-0x18(%rbp)
0.03 │1 38: mov -0x18(%rbp),%rax
0.03 │ mov -0x10(%rbp),%rcx
│ shr $0x1,%rcx
3.63 │ ┌──cmp %rcx,%rax
│ ├──jae 6f
│ │ if (num % i == 0)
0.03 │ │ mov -0x10(%rbp),%rax
│ │ xor %edx,%edx
89.00 │ │ divq -0x18(%rbp)
│ │ cmp $0x0,%rdx
0.22 │ │↓ jne 5f
│ │ return false;
│ │ movb $0x0,-0x1(%rbp)
│ │↓ jmp 73
│ │ }
3.22 │1 5f:│↓ jmp 61
│ │ for(uint64_t i = 3; i < num / 2; i+= 2) {
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D44892
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337789 91177308-0d34-0410-b5e6-96231b3b80d8
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
I replaced all uses of LLVM_ON_WIN32 with _WIN32 in r331127 (llvm),
r331069 (clang), r329697 (lldb), r329696 (lld), r329696 (clang-tools-extra).
If your out-of-tree program used LLVM_ON_WIN32, just use _WIN32 instead, which
is set at exactly the same time to exactly the same value.
https://reviews.llvm.org/D46264
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331224 91177308-0d34-0410-b5e6-96231b3b80d8
These used to be set in the old autoconf build, but the cmake build has had a
"TODO: actually check for these" comment since it was checked in, and they
were set to 1 on mingw unconditionally. It seems safe to say that they always
exist under mingw, so just remove them and assume they're set exactly when on
mingw (with msvc, we use `pragma comment` instead of linking these via flags).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328992 91177308-0d34-0410-b5e6-96231b3b80d8
The autoconf manual: "This macro is obsolescent, as all current systems with
directory libraries have <dirent.h>. New programs need not use this macro."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328989 91177308-0d34-0410-b5e6-96231b3b80d8
These should exist in all toolchains LLVM supports nowadays.
Enables making DataTypes.h a regular header instead of a .h.cmake file and
allows deleting a bunch of cmake goop (which should also speed up cmake
configure time a bit).
All the code this removes is 9+ years old.
https://reviews.llvm.org/D45155
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328970 91177308-0d34-0410-b5e6-96231b3b80d8
Found by looking through the output of
for f in $(grep -o '\bHAVE_[A-Z0-9_]*\b' llvm/cmake/config-ix.cmake); do
echo $f $(git grep $f '*' | wc -l);
done
in the monorepo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328957 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
This re-commit fixes a missing include of <vector> which it seems clang didn't
mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector
only being forward declared at the point of use since it was fully defined
eventually but G++/MSVC both rejected it at the point of use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326738 91177308-0d34-0410-b5e6-96231b3b80d8
Despite building cleanly on my machine in three separate configs, it's failing on pretty much all bots due to missing includes among other things. Investigating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326726 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326723 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV,
causes TableGen to instrument the generated table to collect rule coverage
information. However, LLVM_ENABLE_GISEL_COV goes a bit further than
LLVM_ENABLE_DAGISEL_COV. The information is written to files
(${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be
concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will
read this information and use it to emit warnings about untested rules.
This technique could also be used by SelectionDAG and can be further
extended to detect hot rules and give them priority over colder rules.
Usage:
* Enable LLVM_ENABLE_GISEL_COV in CMake
* Build the compiler and run some tests
* cat gisel-coverage-[0-9]* > gisel-coverage-all
* Delete lib/Target/*/*GenGlobalISel.inc*
* Build the compiler
Known issues:
* ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual
step due to a lack of a portable 'cat' command. It should be the
concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files.
* There's no mechanism to discard coverage information when the ruleset
changes
Depends on D39742
Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka
Reviewed By: rovka
Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39747
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318356 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315590 91177308-0d34-0410-b5e6-96231b3b80d8
But now include a check for CPU_COUNT so we still build on 10 year old
versions of glibc.
Original message:
Use sched_getaffinity instead of std:🧵:hardware_concurrency.
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314931 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This reverts D38481. The change breaks systems with older versions of glibc. It
injects a use of CPU_COUNT() from sched.h without checking to ensure that the
function exists first.
Reviewers:
Subscribers:
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314922 91177308-0d34-0410-b5e6-96231b3b80d8
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314809 91177308-0d34-0410-b5e6-96231b3b80d8
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305632 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Reverse iteration can be turned on, by default, by setting -DLLVM_REVERSE_ITERATION:BOOL=ON during cmake.
With this enabled, we can uncover lots of cases of non-determinism in codegen by simply running our tests (without any other change).
We can then setup a buildbot which will have this turned on by default. Initially, a lot of unit tests will fail in this configuration.
Once we start fixing non-determinism issues, we can gradually make this a blocker for patches.
Reviewers: davide, dblaikie, mehdi_amini, dberlin
Reviewed By: dblaikie
Subscribers: probinson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33908
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304757 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Since LLVM_NATIVE_ARCH, LLVM_NATIVE_ASMPARSER, LLVM_NATIVE_ASMPRINTER,
LLVM_NATIVE_DISASSEMBLER, LLVM_NATIVE_TARGET, LLVM_NATIVE_TARGETINFO and
LLVM_NATIVE_TARGETMC are already defined in llvm-config.h, there seems
to be no reason to also define them in config.h. Also, I can only find
usage of these macros in files that include llvm-config.h.
So let's remove the duplicated macros from config.h.
Reviewers: chandlerc, rnk, mehdi_amini, joerg
Reviewed By: rnk
Subscribers: chapuni, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33881
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304714 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
VersionPrinter by default outputs information about the Host CPU
and Default target. Printing this information requires linking in
a large amount of data, such as supported target triples as C
strings, which in turn bloats the binary size.
Enable a new CMake option LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO
which controls printing of the host and target info. This allows
the target triple names to be dead-code stripped. This is a nice
win for LLVM clients that wish to minimize their binary size, such
as graphics drivers.
By default this is ON, so there is no change in the default behavior.
Clients who wish to suppress this printing can do so by setting this
option to off via CMake.
A test app on Linux that uses ParseCommandLineOptions() shows a binary
size reduction of 23KB (from 149K to 126K) for a Release build, and 24KB
(from 135K to 111K) in a MinSizeRel build.
Reviewers: klimek, beanz, bogner, chandlerc, compnerd
Reviewed By: compnerd
Patch by pammon (Peter Ammon) !
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30904
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300630 91177308-0d34-0410-b5e6-96231b3b80d8
On FreeBSD backtrace is not part of libc and depends on libexecinfo
being available. Instead of using manual checks we can use the builtin
CMake module FindBacktrace.cmake to detect availability of backtrace()
in a portable way.
Patch By: Alex Richardson
Differential Revision: https://reviews.llvm.org/D27143
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300062 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to my change in r295090, which added support for
disabling these checks selectively based on setting the preprocessor
macro without relying on the Cmake setting. Swift has moved over to use
that approach, so we can clean up here and remove the Cmake setting.
https://reviews.llvm.org/D30578
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297109 91177308-0d34-0410-b5e6-96231b3b80d8
In r288754, Mehdi added a cmake option to disable enforcement of the ABI
breaking checks in the "abi-breaking.h" header. We used that when building
Swift and it works, but I think it will be better to control this with a
preprocessor macro instead of a cmake option. That will let us opt out of
the enforcement more selectively.
This change allows skipping the cmake setting if the existing preprocessor
macro is already defined. My intention here is to make this change and get
Swift to use it, and then after a few weeks, we can remove the cmake option.
I want to stage it like that to be less disruptive. I'm not aware of anyone
else using that cmake option.
Mehdi had some initial concern about the impact of using a preprocessor
macro when building with modules enabled. I don't think that will be a
problem if we set the macro on the command line with a -D option in those
contexts where we need to disable the enforcement of the checks.
https://reviews.llvm.org/D29919
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295090 91177308-0d34-0410-b5e6-96231b3b80d8
It appears to be dead, and it needlessly caused me to rebuild all of
LLVM when I changed CMAKE_INSTALL_PREFIX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293574 91177308-0d34-0410-b5e6-96231b3b80d8
