2020-07-25 00:47:38 +02:00
include ( GetLibraryName )
2021-07-16 05:32:59 +02:00
# Ensure that libSupport does not carry any static global initializer.
# libSupport can be embedded in use cases where we don't want to load all
# cl::opt unless we want to parse the command line.
# ManagedStatic can be used to enable lazy-initialization of globals.
# We don't use `add_flag_if_supported` as instead of compiling an empty file we
# check if the current platform is able to compile global std::mutex with this
# flag (Linux can, Darwin can't for example).
check_cxx_compiler_flag ( "-Werror=global-constructors" HAS_WERROR_GLOBAL_CTORS )
if ( HAS_WERROR_GLOBAL_CTORS )
SET ( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror=global-constructors" )
CHECK_CXX_SOURCE_COMPILES ( "
#include <mutex>
s t a t i c s t d : : m u t e x T e s t G l o b a l C t o r D t o r ;
s t a t i c s t d : : r e c u r s i v e _ m u t e x T e s t G l o b a l C t o r D t o r 2 ;
i n t main ( ) { ( v o i d ) T e s t G l o b a l C t o r D t o r ; ( v o i d ) T e s t G l o b a l C t o r D t o r 2 ; r e t u r n 0 ; }
" L L V M _ H A S _ N O G L O B A L _ C T O R _ M U T E X )
if ( NOT LLVM_HAS_NOGLOBAL_CTOR_MUTEX )
string ( REPLACE "-Werror=global-constructors" "" CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS } )
endif ( )
endif ( )
2020-04-30 22:07:13 +02:00
if ( LLVM_ENABLE_ZLIB )
set ( imported_libs ZLIB::ZLIB )
2020-01-02 16:35:22 +01:00
endif ( )
2020-04-30 22:07:13 +02:00
2016-02-09 20:41:14 +01:00
if ( MSVC OR MINGW )
# libuuid required for FOLDERID_Profile usage in lib/Support/Windows/Path.inc.
2018-02-23 13:20:26 +01:00
# advapi32 required for CryptAcquireContextW in lib/Support/Windows/Path.inc.
set ( system_libs ${ system_libs } psapi shell32 ole32 uuid advapi32 )
2016-02-09 20:41:14 +01:00
elseif ( CMAKE_HOST_UNIX )
if ( HAVE_LIBRT )
set ( system_libs ${ system_libs } rt )
endif ( )
if ( HAVE_LIBDL )
set ( system_libs ${ system_libs } ${ CMAKE_DL_LIBS } )
endif ( )
Fix llvm-config --system-libs output on FreeBSD and NetBSD
Summary:
For various reasons, CMake's detection mechanism for `backtrace()`
returns an absolute path `/usr/lib/libexecinfo.so` on FreeBSD and
NetBSD.
Since `tools/llvm-config/CMakeLists.txt` only checks if system
libraries start with `-`, this causes `llvm-config --system-libs` to
produce the following incorrect output:
```
-lrt -l/usr/lib/libexecinfo.so -ltinfo -lpthread -lz -lm
```
Fix it by removing the path and the `lib` prefix, to make it look like a
regular short library name, suitable for appending to a `-l` link flag.
This also fixes the `Bindings/Go/go.test` test case, since that always
died with "unable to find library -l/usr/lib/libexecinfo.so".
Reviewers: chandlerc, emaste, joerg, krytarowski
Reviewed By: krytarowski
Subscribers: hans, bdrewery, mgorny, hintonda, llvm-commits
Differential Revision: https://reviews.llvm.org/D42702
llvm-svn: 326358
2018-02-28 21:04:21 +01:00
if ( HAVE_BACKTRACE AND NOT "${Backtrace_LIBRARIES}" STREQUAL "" )
# On BSDs, CMake returns a fully qualified path to the backtrace library.
# We need to remove the path and the 'lib' prefix, to make it look like a
# regular short library name, suitable for appending to a -l link flag.
get_filename_component ( Backtrace_LIBFILE ${ Backtrace_LIBRARIES } NAME_WE )
STRING ( REGEX REPLACE "^lib" "" Backtrace_LIBFILE ${ Backtrace_LIBFILE } )
set ( system_libs ${ system_libs } ${ Backtrace_LIBFILE } )
2017-04-12 15:51:00 +02:00
endif ( )
2020-09-01 00:11:39 +02:00
if ( LLVM_ENABLE_TERMINFO )
set ( imported_libs ${ imported_libs } "${TERMINFO_LIB}" )
2016-02-09 20:41:14 +01:00
endif ( )
2020-02-18 08:52:29 +01:00
if ( LLVM_ENABLE_THREADS AND ( HAVE_LIBATOMIC OR HAVE_CXX_LIBATOMICS64 ) )
2016-02-09 20:41:14 +01:00
set ( system_libs ${ system_libs } atomic )
endif ( )
2017-02-10 02:59:20 +01:00
set ( system_libs ${ system_libs } ${ LLVM_PTHREAD_LIB } )
2016-02-26 18:01:45 +01:00
if ( UNIX AND NOT ( BEOS OR HAIKU ) )
set ( system_libs ${ system_libs } m )
endif ( )
2018-06-07 23:01:32 +02:00
if ( FUCHSIA )
set ( system_libs ${ system_libs } zircon )
endif ( )
2021-01-27 05:10:34 +01:00
if ( HAIKU )
add_definitions ( -D_BSD_SOURCE )
set ( system_libs ${ system_libs } bsd )
endif ( )
2016-02-09 20:41:14 +01:00
endif ( MSVC OR MINGW )
2014-11-07 17:08:19 +01:00
[cmake] Speed up check-llvm 5x by delay loading shell32 and ole32
Summary:
Previously, check-llvm on my Windows 10 workstation took about 300s to
run, and it would lock up my mouse. Now, it takes just under 60s.
Previously running the tests only used about 15% of the available CPU
time, now it uses up to 60%.
Shell32.dll and ole32.dll have direct dependencies on user32.dll and
gdi32.dll. These DLLs are mostly used to for Windows GUI functionality,
which most LLVM tools don't need. It seems that these DLLs acquire and
release some system resources on startup and exit, and that requires
acquiring the same highly contended lock discussed in this post:
https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/
Most LLVM tools still have a transitive dependency on
SHGetKnownFolderPathW, which is used to look up the user home directory
and local AppData directory. We also use SHFileOperationW to recursively
delete a directory, but only LLDB and clang-doc use this today. At some
point, we might consider removing these last shell32.dll deps, but for
now, I would like to take this free performance.
Many thanks to Bruce Dawson for suggesting this fix. He looked at an ETW
trace of an LLVM test run, noticed these DLLs, and suggested avoiding
them.
Reviewers: zturner, pcc, thakis
Subscribers: mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D51952
llvm-svn: 342002
2018-09-12 00:25:13 +02:00
# Delay load shell32.dll if possible to speed up process startup.
set ( delayload_flags )
if ( MSVC )
set ( delayload_flags delayimp -delayload:shell32.dll -delayload:ole32.dll )
endif ( )
2019-03-25 18:47:45 +01:00
# Link Z3 if the user wants to build it.
if ( LLVM_WITH_Z3 )
2020-08-26 01:19:58 +02:00
set ( system_libs ${ system_libs } ${ Z3_LIBRARIES } )
2019-03-25 18:47:45 +01:00
endif ( )
[Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}
This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree.
To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc.
When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future.
When enabled, this changes the memory stack from:
new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc
to:
new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc
The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration.
Differential Revision: https://reviews.llvm.org/D71786
2020-08-27 17:09:20 +02:00
# Override the C runtime allocator on Windows and embed it into LLVM tools & libraries
if ( LLVM_INTEGRATED_CRT_ALLOC )
if ( CMAKE_BUILD_TYPE AND NOT ${ LLVM_USE_CRT_${uppercase_CMAKE_BUILD_TYPE } } MATCHES "^(MT|MTd)$" )
message ( FATAL_ERROR "LLVM_INTEGRATED_CRT_ALLOC only works with /MT or /MTd. Use LLVM_USE_CRT_${uppercase_CMAKE_BUILD_TYPE} to set the appropriate option." )
endif ( )
string ( REGEX REPLACE "(/|\\\\)$" "" LLVM_INTEGRATED_CRT_ALLOC "${LLVM_INTEGRATED_CRT_ALLOC}" )
if ( NOT EXISTS "${LLVM_INTEGRATED_CRT_ALLOC}" )
message ( FATAL_ERROR "Cannot find the path to `git clone` for the CRT allocator! (${LLVM_INTEGRATED_CRT_ALLOC}). Currently, rpmalloc, snmalloc and mimalloc are supported." )
endif ( )
if ( LLVM_INTEGRATED_CRT_ALLOC MATCHES "rpmalloc$" )
add_definitions ( -DENABLE_OVERRIDE -DENABLE_PRELOAD )
set ( ALLOCATOR_FILES "${LLVM_INTEGRATED_CRT_ALLOC}/rpmalloc/rpmalloc.c" )
elseif ( LLVM_INTEGRATED_CRT_ALLOC MATCHES "snmalloc$" )
set ( ALLOCATOR_FILES "${LLVM_INTEGRATED_CRT_ALLOC}/src/override/malloc.cc" "${LLVM_INTEGRATED_CRT_ALLOC}/src/override/new.cc" )
set ( system_libs ${ system_libs } "mincore.lib" "-INCLUDE:malloc" )
elseif ( LLVM_INTEGRATED_CRT_ALLOC MATCHES "mimalloc$" )
set ( MIMALLOC_LIB "${LLVM_INTEGRATED_CRT_ALLOC}/out/msvc-x64/Release/mimalloc-static.lib" )
if ( NOT EXISTS "${MIMALLOC_LIB}" )
message ( FATAL_ERROR "Cannot find the mimalloc static library. To build it, first apply the patch from https://github.com/microsoft/mimalloc/issues/268 then build the Release x64 target through ${LLVM_INTEGRATED_CRT_ALLOC}\\ide\\vs2019\\mimalloc.sln" )
endif ( )
set ( system_libs ${ system_libs } "${MIMALLOC_LIB}" "-INCLUDE:malloc" )
endif ( )
endif ( )
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so. Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:
1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so. This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.
With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.
2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set. This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.
I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:
- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON
Reviewers: beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70179
2019-11-14 06:39:58 +01:00
add_llvm_component_library ( LLVMSupport
2018-11-28 12:38:10 +01:00
A A r c h 6 4 T a r g e t P a r s e r . c p p
2019-09-11 00:05:01 +02:00
A B I B r e a k . c p p
2018-11-28 12:38:10 +01:00
A R M T a r g e t P a r s e r . c p p
2017-10-12 00:18:53 +02:00
A M D G P U M e t a d a t a . c p p
2020-07-16 13:56:07 +02:00
A P F i x e d P o i n t . c p p
2008-09-22 03:08:49 +02:00
A P F l o a t . c p p
A P I n t . c p p
A P S I n t . c p p
2014-01-19 09:25:27 +01:00
A R M B u i l d A t t r s . c p p
2017-01-13 11:50:01 +01:00
A R M A t t r i b u t e P a r s e r . c p p
2014-06-02 03:17:49 +02:00
A R M W i n E H . c p p
2008-09-22 03:08:49 +02:00
A l l o c a t o r . c p p
2021-05-03 14:49:35 +02:00
A u t o C o n v e r t . c p p
2017-03-02 21:52:51 +01:00
B i n a r y S t r e a m E r r o r . c p p
B i n a r y S t r e a m R e a d e r . c p p
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-17 22:23:31 +02:00
B i n a r y S t r e a m R e f . c p p
2017-03-02 21:52:51 +01:00
B i n a r y S t r e a m W r i t e r . c p p
2011-07-26 00:24:51 +02:00
B l o c k F r e q u e n c y . c p p
2011-06-11 03:05:22 +02:00
B r a n c h P r o b a b i l i t y . c p p
2018-11-17 19:03:47 +01:00
B u r y P o i n t e r . c p p
2016-04-02 05:28:26 +02:00
C a c h e P r u n i n g . c p p
2009-12-23 18:03:46 +01:00
c i r c u l a r _ r a w _ o s t r e a m . c p p
2016-10-20 14:05:50 +02:00
C h r o n o . c p p
2015-04-27 19:19:26 +02:00
C O M . c p p
[globalisel][tablegen] Generate rule coverage and use it to identify untested rules
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
llvm-svn: 318356
2017-11-16 01:46:35 +01:00
C o d e G e n C o v e r a g e . c p p
2008-09-22 03:08:49 +02:00
C o m m a n d L i n e . c p p
2013-04-23 10:28:39 +02:00
C o m p r e s s i o n . c p p
2019-04-08 14:31:12 +02:00
C R C . c p p
2016-09-30 02:38:45 +02:00
C o n v e r t U T F . c p p
2013-01-30 13:05:05 +01:00
C o n v e r t U T F W r a p p e r . c p p
2010-07-28 19:17:46 +02:00
C r a s h R e c o v e r y C o n t e x t . c p p
2011-09-13 21:42:16 +02:00
D a t a E x t r a c t o r . c p p
2008-09-22 03:08:49 +02:00
D e b u g . c p p
Add initial support for debug counting
Summary:
We have support for bisection, and bugpoint can reduce testcases
often to a single pass. But that doesn't help reduce it to a single
transform by a single pass. Which debug counting lets us do.
Debug counting lets you instrument a pass so that it only executes a
certain thing (rwhatever you want) after skipping it a certain time of
times, and then only does a certain number of executions before saying
"skip" again.
To make it concrete, for predicateinfo, if i instrument use renaming,
i can make it so it skips renaming the first N uses, renames the next
N, and then skips the rest.
This lets you narrow down a miscompilation to, often, a single
transformation, and then also debug it (by using the same command line
parameters).
Reviewers: chandlerc, davide, mehdi_amini
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29998
llvm-svn: 295593
2017-02-19 05:28:56 +01:00
D e b u g C o u n t e r . c p p
2009-12-03 12:12:42 +01:00
D e l t a A l g o r i t h m . c p p
2010-06-08 18:21:22 +02:00
D A G D e l t a A l g o r i t h m . c p p
2018-01-28 12:05:10 +01:00
D J B . c p p
2020-02-04 15:20:10 +01:00
E L F A t t r i b u t e P a r s e r . c p p
E L F A t t r i b u t e s . c p p
2016-03-24 00:57:28 +01:00
E r r o r . c p p
2009-07-07 20:52:14 +02:00
E r r o r H a n d l i n g . c p p
2020-04-13 22:29:59 +02:00
E x t e n s i b l e R T T I . c p p
2019-07-25 00:59:20 +02:00
F i l e C o l l e c t o r . c p p
2008-09-22 03:08:49 +02:00
F i l e U t i l i t i e s . c p p
2012-08-01 04:29:50 +02:00
F i l e O u t p u t B u f f e r . c p p
2008-09-22 03:08:49 +02:00
F o l d i n g S e t . c p p
2009-07-14 22:44:17 +02:00
F o r m a t t e d S t r e a m . c p p
2016-11-12 00:57:40 +01:00
F o r m a t V a r i a d i c . c p p
2016-12-21 00:09:09 +01:00
G l o b P a t t e r n . c p p
2008-09-22 03:08:49 +02:00
G r a p h W r i t e r . c p p
Rewrite LLVM's generalized support library for hashing to follow the API
of the proposed standard hashing interfaces (N3333), and to use
a modified and tuned version of the CityHash algorithm.
Some of the highlights of this change:
-- Significantly higher quality hashing algorithm with very well
distributed results, and extremely few collisions. Should be close to
a checksum for up to 64-bit keys. Very little clustering or clumping of
hash codes, to better distribute load on probed hash tables.
-- Built-in support for reserved values.
-- Simplified API that composes cleanly with other C++ idioms and APIs.
-- Better scaling performance as keys grow. This is the fastest
algorithm I've found and measured for moderately sized keys (such as
show up in some of the uniquing and folding use cases)
-- Support for enabling per-execution seeds to prevent table ordering
or other artifacts of hashing algorithms to impact the output of
LLVM. The seeding would make each run different and highlight these
problems during bootstrap.
This implementation was tested extensively using the SMHasher test
suite, and pased with flying colors, doing better than the original
CityHash algorithm even.
I've included a unittest, although it is somewhat minimal at the moment.
I've also added (or refactored into the proper location) type traits
necessary to implement this, and converted users of GeneralHash over.
My only immediate concerns with this implementation is the performance
of hashing small keys. I've already started working to improve this, and
will continue to do so. Currently, the only algorithms faster produce
lower quality results, but it is likely there is a better compromise
than the current one.
Many thanks to Jeffrey Yasskin who did most of the work on the N3333
paper, pair-programmed some of this code, and reviewed much of it. Many
thanks also go to Geoff Pike Pike and Jyrki Alakuijala, the original
authors of CityHash on which this is heavily based, and Austin Appleby
who created MurmurHash and the SMHasher test suite.
Also thanks to Nadav, Tobias, Howard, Jay, Nick, Ahmed, and Duncan for
all of the review comments! If there are further comments or concerns,
please let me know and I'll jump on 'em.
llvm-svn: 151822
2012-03-01 19:55:25 +01:00
H a s h i n g . c p p
2018-04-13 20:26:06 +02:00
I n i t L L V M . c p p
2020-11-10 12:09:20 +01:00
I n s t r u c t i o n C o s t . c p p
2010-12-21 01:04:46 +01:00
I n t E q C l a s s e s . c p p
2010-11-19 05:47:19 +01:00
I n t e r v a l M a p . c p p
2018-08-25 00:31:51 +02:00
I t a n i u m M a n g l i n g C a n o n i c a l i z e r . c p p
Lift JSON library from clang-tools-extra/clangd to llvm/Support.
Summary:
This consists of four main parts:
- an type json::Expr representing JSON values of dynamic kind, which can be
composed, inspected, and modified
- a JSON parser from string -> json::Expr
- a JSON printer from json::Expr -> string, with optional pretty-printing
- a convention for mapping json::Expr <=> native types (fromJSON/toJSON)
Mapping functions are provided for primitives (e.g. int, vector) and the
ObjectMapper helper helps implement fromJSON for struct/object types.
Based on clangd's usage, a couple of places I'd appreciate review attention:
- fromJSON returns only bool. A richer error-signaling mechanism may be useful
to provide useful messages, or let recursive fromJSONs (containers/structs)
do careful error recovery.
- should json::obj be always explicitly written (like json::ary)
- there's no streaming parse API. I suspect there are some simple wins like
a callback API where the document is a long array, and each element is small.
But this can probably be bolted on easily when we see the need.
Reviewers: bkramer, labath
Subscribers: mgorny, ilya-biryukov, ioeric, MaskRay, llvm-commits
Differential Revision: https://reviews.llvm.org/D45753
llvm-svn: 336534
2018-07-09 12:05:41 +02:00
J S O N . c p p
2017-08-08 18:29:35 +02:00
K n o w n B i t s . c p p
2014-02-22 16:39:39 +01:00
L E B 1 2 8 . c p p
2013-12-27 05:28:57 +01:00
L i n e I t e r a t o r . c p p
2012-04-17 22:03:03 +02:00
L o c a l e . c p p
2012-01-29 21:15:10 +01:00
L o c k F i l e M a n a g e r . c p p
Recommit: [globalisel] Change LLT constructor string into an LLT-based object that knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
The problem with the previous commit appears to have been that TableGen was including CodeGen/LowLevelType.h instead of Support/LowLevelTypeImpl.h.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297241
2017-03-08 00:20:35 +01:00
L o w L e v e l T y p e . c p p
2008-09-22 03:08:49 +02:00
M a n a g e d S t a t i c . c p p
2014-09-27 16:41:29 +02:00
M a t h E x t r a s . c p p
2020-04-24 13:22:40 +02:00
M e m A l l o c . c p p
2008-09-22 03:08:49 +02:00
M e m o r y B u f f e r . c p p
2020-10-13 00:41:15 +02:00
M e m o r y B u f f e r R e f . c p p
2013-05-21 03:30:38 +02:00
M D 5 . c p p
2016-10-11 21:24:45 +02:00
N a t i v e F o r m a t t i n g . c p p
2020-04-10 06:13:49 +02:00
O p t i m i z e d S t r u c t L a y o u t . c p p
2019-01-18 13:52:03 +01:00
O p t i o n a l . c p p
2017-05-11 02:03:52 +02:00
P a r a l l e l . c p p
2008-09-22 03:08:49 +02:00
P l u g i n L o a d e r . c p p
2009-03-05 10:19:13 +01:00
P r e t t y S t a c k T r a c e . c p p
2014-06-25 17:21:42 +02:00
R a n d o m N u m b e r G e n e r a t o r . c p p
2009-09-01 19:01:02 +02:00
R e g e x . c p p
2020-02-04 15:20:10 +01:00
R I S C V A t t r i b u t e s . c p p
R I S C V A t t r i b u t e P a r s e r . c p p
2014-06-20 23:47:47 +02:00
S c a l e d N u m b e r . c p p
2016-05-03 02:28:04 +02:00
S c o p e d P r i n t e r . c p p
2016-04-01 06:30:16 +02:00
S H A 1 . c p p
2021-02-14 18:31:44 +01:00
S H A 2 5 6 . c p p
2019-02-19 19:18:31 +01:00
S i g n p o s t s . c p p
2008-09-22 03:08:49 +02:00
S m a l l P t r S e t . c p p
2009-12-16 09:44:24 +01:00
S m a l l V e c t o r . c p p
2009-06-21 05:41:50 +02:00
S o u r c e M g r . c p p
2014-07-09 21:40:08 +02:00
S p e c i a l C a s e L i s t . c p p
2008-09-22 03:08:49 +02:00
S t a t i s t i c . c p p
S t r i n g E x t r a s . c p p
S t r i n g M a p . c p p
2015-06-13 14:49:52 +02:00
S t r i n g S a v e r . c p p
2009-09-17 00:38:48 +02:00
S t r i n g R e f . c p p
2020-04-09 00:21:49 +02:00
S u f f i x T r e e . c p p
2018-09-13 20:51:44 +02:00
S y m b o l R e m a p p i n g R e a d e r . c p p
2008-09-22 03:08:49 +02:00
S y s t e m U t i l s . c p p
2017-01-06 03:29:48 +01:00
T a r W r i t e r . c p p
TargetParser: FPU/ARCH/EXT parsing refactory - NFC
This new class in a global context contain arch-specific knowledge in order
to provide LLVM libraries, tools and projects with the ability to understand
the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are
supported.
Current behaviour it to parse from free-text to enum values and back, so that
all users can share the same parser and codes. This simplifies a lot both the
ASM/Obj streamers in the back-end (where this came from), and the front-end
parsers for command line arguments (where this is going to be used next).
The previous implementation, using .def/.h includes is deprecated due to its
inflexibility to be built without the backend support and for being too
cumbersome. As more architectures join this scheme, and as more features of
such architectures are added (such as hardware features, type sizes, etc) into
a full blown TargetDescription class, having a set of classes is the most
sane implementation.
The ultimate goal of this refactor both LLVM's and Clang's target description
classes into one unique interface, so that we can de-duplicate and standardise
the descriptions, as well as make it available for other front-ends, tools,
etc.
The FPU parsing for command line options in Clang has been converted to use
this new library and a number of aliases were added for compatibility:
* A bogus neon-vfpv3 alias (neon defaults to vfp3)
* armv5/v6
* {fp4/fp5}-{sp/dp}-d16
Next steps:
* Port Clang's ARCH/EXT parsing to use this library.
* Create a TableGen back-end to generate this information.
* Run this TableGen process regardless of which back-ends are built.
* Expose more information and rename it to TargetDescription.
* Continue re-factoring Clang to use as much of it as possible.
llvm-svn: 236900
2015-05-08 23:04:27 +02:00
T a r g e t P a r s e r . c p p
2015-12-15 01:59:19 +01:00
T h r e a d P o o l . c p p
2019-03-30 09:42:48 +01:00
T i m e P r o f i l e r . c p p
2008-09-22 03:08:49 +02:00
T i m e r . c p p
2010-10-08 01:12:15 +02:00
T o o l O u t p u t F i l e . c p p
Use trigrams to speed up SpecialCaseList.
Summary:
it's often the case when the rules in the SpecialCaseList
are of the form hel.o*bar. That gives us a chance to build
trigram index to quickly discard 99% of inputs without
running a full regex. A similar idea was used in Google Code Search
as described in the blog post:
https://swtch.com/~rsc/regexp/regexp4.html
The check is defeated, if there's at least one regex
more complicated than that. In this case, all inputs
will go through the regex. That said, the real-world
rules are often simple or can be simplied. That considerably
speeds up compiling Chromium with CFI and UBSan.
As measured on Chromium's content_message_generator.cc:
before, CFI: 44 s
after, CFI: 23 s
after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference)
after, regular compilation to bitcode: 23 s
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27188
llvm-svn: 288303
2016-12-01 03:54:54 +01:00
T r i g r a m I n d e x . c p p
2009-05-27 18:52:17 +02:00
T r i p l e . c p p
2009-07-24 09:04:49 +02:00
T w i n e . c p p
Always emit error for wrong interfaces to scalable vectors, unless cmdline flag is passed.
In order to bring up scalable vector support in LLVM incrementally,
we introduced behaviour to emit a warning, instead of an error, when
asking the wrong question of a scalable vector, like asking for the
fixed number of elements.
This patch puts that behaviour under a flag. The default behaviour is
that the compiler will always error, which means that all LLVM unit
tests and regression tests will now fail when a code-path is taken that
still uses the wrong interface.
The behaviour to demote an error to a warning can be individually enabled
for tools that want to support experimental use of scalable vectors.
This patch enables that behaviour when driving compilation from Clang.
This means that for users who want to try out scalable-vector support,
fixed-width codegen support, or build user-code with scalable vector
intrinsics, Clang will not crash and burn when the compiler encounters
such a case.
This allows us to do away with the following pattern in many of the SVE tests:
RUN: .... 2>%t
RUN: cat %t | FileCheck --check-prefix=WARN
WARN-NOT: warning: ...
The behaviour to emit warnings is only temporary and we expect this flag
to be removed in the future when scalable vector support is more stable.
This patch also has fixes the following tests:
unittests:
ScalableVectorMVTsTest.SizeQueries
SelectionDAGAddressAnalysisTest.unknownSizeFrameObjects
AArch64SelectionDAGTest.computeKnownBitsSVE_ZERO_EXTEND_VECTOR_INREG
regression tests:
Transforms/InstCombine/vscale_gep.ll
Reviewed By: paulwalker-arm, ctetreau
Differential Revision: https://reviews.llvm.org/D98856
2021-03-17 22:35:09 +01:00
T y p e S i z e . c p p
2013-09-04 18:00:12 +02:00
U n i c o d e . c p p
Resubmit r325107 (case folding DJB hash)
The issue was that the has function was generating different results depending
on the signedness of char on the host platform. This commit fixes the issue by
explicitly using an unsigned char type to prevent sign extension and
adds some extra tests.
The original commit message was:
This patch implements a variant of the DJB hash function which folds the
input according to the algorithm in the Dwarf 5 specification (Section
6.1.1.4.5), which in turn references the Unicode Standard (Section 5.18,
"Case Mappings").
To achieve this, I have added a llvm::sys::unicode::foldCharSimple
function, which performs this mapping. The implementation of this
function was generated from the CaseMatching.txt file from the Unicode
spec using a python script (which is also included in this patch). The
script tries to optimize the function by coalescing adjecant mappings
with the same shift and stride (terms I made up). Theoretically, it
could be made a bit smarter and merge adjecant blocks that were
interrupted by only one or two characters with exceptional mapping, but
this would save only a couple of branches, while it would greatly
complicate the implementation, so I deemed it was not worth it.
Since we assume that the vast majority of the input characters will be
US-ASCII, the folding hash function has a fast-path for handling these,
and only whips out the full decode+fold+encode logic if we encounter a
character outside of this range. It might be possible to implement the
folding directly on utf8 sequences, but this would also bring a lot of
complexity for the few cases where we will actually need to process
non-ascii characters.
Reviewers: JDevlieghere, aprantl, probinson, dblaikie
Subscribers: mgorny, hintonda, echristo, clayborg, vleschuk, llvm-commits
Differential Revision: https://reviews.llvm.org/D42740
llvm-svn: 325732
2018-02-21 23:36:31 +01:00
U n i c o d e C a s e F o l d . c p p
2018-06-11 12:28:04 +02:00
V e r s i o n T u p l e . c p p
2018-10-10 15:27:25 +02:00
V i r t u a l F i l e S y s t e m . c p p
2018-03-09 10:56:24 +01:00
W i t h C o l o r . c p p
2020-06-09 21:18:08 +02:00
X 8 6 T a r g e t P a r s e r . c p p
2012-04-04 01:09:22 +02:00
Y A M L P a r s e r . c p p
2012-12-12 21:46:15 +01:00
Y A M L T r a i t s . c p p
2009-08-25 02:02:29 +02:00
r a w _ o s _ o s t r e a m . c p p
2008-09-22 03:08:49 +02:00
r a w _ o s t r e a m . c p p
2009-08-30 10:24:09 +02:00
r e g c o m p . c
r e g e r r o r . c
r e g e x e c . c
r e g f r e e . c
r e g s t r l c p y . c
2016-09-27 17:45:57 +02:00
x x h a s h . c p p
2019-03-25 18:47:45 +01:00
Z 3 S o l v e r . c p p
2010-11-29 19:16:10 +01:00
[Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}
This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree.
To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc.
When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future.
When enabled, this changes the memory stack from:
new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc
to:
new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc
The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration.
Differential Revision: https://reviews.llvm.org/D71786
2020-08-27 17:09:20 +02:00
$ { A L L O C A T O R _ F I L E S }
2010-11-29 19:16:10 +01:00
# System
A t o m i c . c p p
D y n a m i c L i b r a r y . c p p
E r r n o . c p p
H o s t . c p p
M e m o r y . c p p
2013-06-26 21:33:03 +02:00
P a t h . c p p
2010-11-29 19:16:10 +01:00
P r o c e s s . c p p
P r o g r a m . c p p
2019-08-16 01:07:20 +02:00
R W M u t e x . c p p
2010-11-29 19:16:10 +01:00
S i g n a l s . c p p
2011-08-24 20:08:43 +02:00
T a r g e t R e g i s t r y . c p p
2010-11-29 19:16:10 +01:00
T h r e a d L o c a l . c p p
T h r e a d i n g . c p p
V a l g r i n d . c p p
2013-03-26 02:29:15 +01:00
W a t c h d o g . c p p
2014-01-20 11:20:23 +01:00
Teach llvm_add_library() to find include dirs.
Since header files are not compilation units, CMake does not require
you to specify them in the CMakeLists.txt file. As a result, unless a
header file is explicitly added, CMake won't know about it, and when
generating IDE-based projects, CMake won't put the header files into
the IDE project. LLVM currently tries to deal with this in two ways:
1) It looks for all .h files that are in the project directory, and
adds those.
2) llvm_add_library() understands the ADDITIONAL_HEADERS argument,
which allows one to list an arbitrary list of headers.
This patch takes things one step further. It adds the ability for
llvm_add_library() to take an ADDITIONAL_HEADER_DIRS argument, which
will specify a list of folders which CMake will glob for header files.
Furthermore, it will glob not only for .h files, but also for .inc
files.
Included in this CL is an update to one of the existing users of
ADDITIONAL_HEADERS to use this new argument instead, to serve as an
illustration of how this cleans up the CMake.
The big advantage of this new approach is that until now, there was no
way for the IDE projects to locate the header files that are in the
include tree. In other words, if you are in, for example,
lib/DebugInfo/DWARF, the corresponding includes for this project will
be located under include/llvm/DebugInfo/DWARF. Now, in the
CMakeLists.txt for lib/DebugInfo/DWARF, you can simply write:
ADDITIONAL_HEADER_DIRS
../../include/llvm/DebugInfo/DWARF
as an argument to llvm_add_library(), and all header files will get
added to the IDE project.
Differential Revision: http://reviews.llvm.org/D7460
Reviewed By: Chris Bieneman
llvm-svn: 228670
2015-02-10 06:04:37 +01:00
A D D I T I O N A L _ H E A D E R _ D I R S
U n i x
W i n d o w s
2016-08-22 22:38:53 +02:00
$ { L L V M _ M A I N _ I N C L U D E _ D I R } / l l v m / A D T
2015-02-11 04:28:02 +01:00
$ { L L V M _ M A I N _ I N C L U D E _ D I R } / l l v m / S u p p o r t
2017-04-12 15:51:00 +02:00
$ { B a c k t r a c e _ I N C L U D E _ D I R S }
2020-10-09 18:41:21 +02:00
L I N K _ L I B S
$ { s y s t e m _ l i b s } $ { i m p o r t e d _ l i b s } $ { d e l a y l o a d _ f l a g s }
L I N K _ C O M P O N E N T S
D e m a n g l e
2014-11-07 17:08:19 +01:00
)
2014-02-26 13:18:55 +01:00
2020-04-30 22:07:13 +02:00
set ( llvm_system_libs ${ system_libs } )
2020-07-25 00:47:38 +02:00
# This block is only needed for llvm-config. When we deprecate llvm-config and
# move to using CMake export, this block can be removed.
2020-04-30 22:07:13 +02:00
if ( LLVM_ENABLE_ZLIB )
# CMAKE_BUILD_TYPE is only meaningful to single-configuration generators.
if ( CMAKE_BUILD_TYPE )
string ( TOUPPER ${ CMAKE_BUILD_TYPE } build_type )
get_property ( zlib_library TARGET ZLIB::ZLIB PROPERTY LOCATION_ ${ build_type } )
endif ( )
if ( NOT zlib_library )
get_property ( zlib_library TARGET ZLIB::ZLIB PROPERTY LOCATION )
endif ( )
2020-07-25 00:47:38 +02:00
get_library_name ( ${ zlib_library } zlib_library )
2020-04-30 22:07:13 +02:00
set ( llvm_system_libs ${ llvm_system_libs } "${zlib_library}" )
endif ( )
2020-09-01 00:11:39 +02:00
if ( LLVM_ENABLE_TERMINFO )
2020-07-25 00:47:38 +02:00
get_library_name ( ${ TERMINFO_LIB } terminfo_library )
2020-09-01 00:11:39 +02:00
set ( llvm_system_libs ${ llvm_system_libs } "${terminfo_library}" )
endif ( )
2020-04-30 22:07:13 +02:00
set_property ( TARGET LLVMSupport PROPERTY LLVM_SYSTEM_LIBS "${llvm_system_libs}" )
2019-03-25 18:47:45 +01:00
2020-09-10 19:32:45 +02:00
if ( LLVM_INTEGRATED_CRT_ALLOC )
if ( LLVM_INTEGRATED_CRT_ALLOC MATCHES "snmalloc$" )
set_property ( TARGET LLVMSupport PROPERTY CXX_STANDARD 17 )
add_definitions ( -D_SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING )
if ( "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" AND
" $ { C M A K E _ S Y S T E M _ P R O C E S S O R } " M A T C H E S " x 8 6 _ 6 4 " )
set_property ( TARGET LLVMSupport PROPERTY COMPILE_FLAGS "-mcx16" )
endif ( )
endif ( )
endif ( )
2019-03-25 18:47:45 +01:00
if ( LLVM_WITH_Z3 )
2021-04-05 17:30:37 +02:00
target_include_directories ( LLVMSupport SYSTEM
P R I V A T E
$ { Z 3 _ I N C L U D E _ D I R }
)
2019-03-25 18:47:45 +01:00
endif ( )