| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extracted
The CodeExtractor is not smart enough to compute which basic block is
the entry of a region. Instead it relies on the order of the list
of basic blocks that is handed to it and assumes that the entry
is the first block in the list.
Without the additional debug information, it is hard to understand
why a valid region does not get extracted, because we would miss
that the order of in the list just doesn't match what the CodeExtractor
wants.
NFC
llvm-svn: 358471
|
|
|
|
| |
llvm-svn: 358470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Apparently, it makes a difference on where a block lives depending on if
it's passed "inline" versus assigned and then passed via a variable.
Both tests in this commit now give a signal, if `Block_copy` is used in
`dispatch_sync`.
Since these tests use different mechanisms (Objective-C retain versus
C++ copy constructor) as proxies to observe if the block was copied, we
should keep both of them.
Commit, that first avoided the unnecessary copy:
faef7d034a9ec6cb757137adce8e8670ec6c2d7b
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D60639
llvm-svn: 358469
|
|
|
|
|
|
|
|
|
|
| |
Most of these headers are still included via transitive includes and
so won't likely show any problems or improvements in incremental
rebuild time.
Differential Revision: https://reviews.llvm.org/D60741
llvm-svn: 358468
|
|
|
|
|
|
| |
incorrectly fire.
llvm-svn: 358467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test in the dependent revision has been fixed for Windows.
Original commit message:
Response file expansion limits the amount of expansion to prevent
potential infinite recursion. However, the current logic assumes that
any argument beginning with @ is a response file, which is not true for
e.g. `-Xlinker -rpath -Xlinker @executable_path/../lib` on Darwin.
Having too many of these non-response file arguments beginning with @
prevents actual response files from being expanded. Instead, limit based
on the number of successful response file expansions, which should still
prevent infinite recursion but also avoid false positives.
Differential Revision: https://reviews.llvm.org/D60631
> llvm-svn: 358452
llvm-svn: 358466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the appropriate tokenizer to fix the test on Windows.
Original commit message:
I'm going to be modifying the logic to avoid infinitely recursing on
self-referential response files, so add a unit test to verify the
expected behavior.
Differential Revision: https://reviews.llvm.org/D60630
> llvm-svn: 358451
llvm-svn: 358465
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB can't currently handle Clang's default (limit/no-standalone) DWARF,
so platforms that default to LLDB (Darwin) or anyone else manually
requesting LLDB tuning, should also get standalone DWARF.
That doesn't mean a user can't explicitly enable (because they have
other reasons to prefer standalone DWARF (such as that they're only
building half their application with debug info enabled, and half
without - or because they're tuning for GDB, but want to be able to use
it under LLDB too (this is the default on FreeBSD))) or disable (testing
LLDB fixes/improvements that handle no-standalone mode, building C code,
perhaps, which wouldn't have the LLDB<>no-standalone conflict, etc) the
feature regardless of the tuning.
llvm-svn: 358464
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 358463
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
anonymous enums correctly
Summary:
https://reviews.llvm.org/D51633 added error handling in the ASTImporter.cpp which uncovered an underlying bug in which we used the wrong name when handling naming conflicts. This could cause a segmentation fault when attempting to cast an int to an enum during expression parsing.
This test should pass once https://reviews.llvm.org/D59665 is committed.
Differential Revision: https://reviews.llvm.org/D59667
llvm-svn: 358462
|
|
|
|
|
|
|
|
|
| |
This reverts r358451 (git commit c8497467edc5766ae81ffbde58159f8c6af50803)
The test breaks a Windows buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/17016/steps/test-check-all/logs/stdio
llvm-svn: 358461
|
|
|
|
|
|
|
|
| |
This reverts r358452 (git commit c8df4fb9c3865eac52a99602c26bbc070098c3d4)
A dependent commit breaks the Windows buildbots.
llvm-svn: 358460
|
|
|
|
|
|
|
|
|
| |
disassembly output"
The test fails on darwin due to a sed error:
sed: 1: "y/\t/ /": transform strings are not the same length
llvm-svn: 358459
|
|
|
|
|
|
|
|
| |
Since non-pow-2 types are going to get split up into multiple loads anyway,
don't do the [SZ]EXTLOAD combine for those and save us trouble later in
legalization.
llvm-svn: 358458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If LSR split critical edge during rewriting phi operands and
phi node has other pending fixup operands, we need to
update those pending fixups. Otherwise formulae will not be
implemented completely and some instructions will not be eliminated.
llvm.org/PR41445
Differential Revision: https://reviews.llvm.org/D60645
Patch by: Denis Bakhvalov <denis.bakhvalov@intel.com>
llvm-svn: 358457
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some environments, argv[0] doesn't hold a valid file name, but
sys::fs::getMainExecutable will find the main executable properly.
This patch tweaks the logic to fall back to sys::fs::getMainExecutable
in more situations.
Differential Revision: https://reviews.llvm.org/D60730
llvm-svn: 358455
|
|
|
|
| |
llvm-svn: 358454
|
|
|
|
| |
llvm-svn: 358453
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Response file expansion limits the amount of expansion to prevent
potential infinite recursion. However, the current logic assumes that
any argument beginning with @ is a response file, which is not true for
e.g. `-Xlinker -rpath -Xlinker @executable_path/../lib` on Darwin.
Having too many of these non-response file arguments beginning with @
prevents actual response files from being expanded. Instead, limit based
on the number of successful response file expansions, which should still
prevent infinite recursion but also avoid false positives.
Differential Revision: https://reviews.llvm.org/D60631
llvm-svn: 358452
|
|
|
|
|
|
|
|
|
|
| |
I'm going to be modifying the logic to avoid infinitely recursing on
self-referential response files, so add a unit test to verify the
expected behavior.
Differential Revision: https://reviews.llvm.org/D60630
llvm-svn: 358451
|
|
|
|
|
|
|
|
| |
512 type.
The 'v' constraint is used to select zmm0-31. This makes 512 bit consistent with 128/256-bit.a
llvm-svn: 358450
|
|
|
|
|
|
| |
of stopping at xmm15. Add an additional dependency to keep instruction below inline asm block.
llvm-svn: 358449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes from Roman's review here: https://reviews.llvm.org/D58675#1465336
Reviewers: lebedev.ri
Subscribers: hiraditya, mgrang, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60663
llvm-svn: 358448
|
|
|
|
| |
llvm-svn: 358447
|
|
|
|
|
|
|
| |
These are artificial, so I think this should only come up with inline
asm comments.
llvm-svn: 358446
|
|
|
|
|
|
|
|
|
|
| |
mode.
After the previous patch with the more correct handling of the number of
threads in parallel regions, the parallel regions with num_threads
clauses can be executed in SPMD mode.
llvm-svn: 358445
|
|
|
|
| |
llvm-svn: 358444
|
|
|
|
|
|
|
| |
This reverts commit r358418 as it broke `test/Object/objdump-export-list`
on Darwin.
llvm-svn: 358443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the kernel is executed in SPMD mode and the L2+ parallel for region
with the dynamic scheduling is executed, dynamic scheduling functions
are called. They expect full runtime support, but SPMD kernels may be
executed without the full runtime. It leads to the runtime crash of the
compiled program. Patch fixes this problem + fixes handling of the
parallelism level in SPMD mode, which is required as part of this patch.
Reviewers: gtbercea, kkwli0, grokos
Subscribers: guansong, jdoerfert, openmp-commits, caomhin
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D60578
llvm-svn: 358442
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC -Wconversion-null warning appeared after 9a63380260860b657b72f07c4f0e61e382ab934a.
There was a similar problem already in the past:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131230/096230.html
Patch committed on behalf of @dendibakh
Differential Revision: https://reviews.llvm.org/D60726
llvm-svn: 358441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Archives can contain multiple members with the same name. This would
cause ThinLTO links to fail ("Expected at most one ThinLTO module per
bitcode file"). This change implements the same strategy we use in
the ELF linker: make the offset in the archive part of the module
name so that names are unique.
Reviewers: pcc, mehdi_amini, ruiu
Reviewed By: ruiu
Subscribers: eraman, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60549
llvm-svn: 358440
|
|
|
|
|
|
| |
Making sure to cover an important legality cornercase.
llvm-svn: 358439
|
|
|
|
|
|
|
|
|
|
| |
This change replaces some of the assembly functions in z_Linux_asm.S
for inline asm in kmp.h. This allows better interaction with compiler
tools and sanitizers.
Differential Revision: https://reviews.llvm.org/D60423
llvm-svn: 358438
|
|
|
|
|
|
|
|
| |
This reverts r358409, which I think broke the bots in compiler-rt.
Since I'm having trouble reproducing the failure, I'm reverting this
until I can investigate locally.
llvm-svn: 358437
|
|
|
|
|
|
|
|
| |
avx512bw.
32 and 64 bit k-registers require avx512bw. If we don't block this properly, it leads to a crash.
llvm-svn: 358436
|
|
|
|
|
|
|
|
| |
by deadcode elimination. Improve CHECK lines to check IR types used. NFC
I plan to use this as the basis for backend IR test cases. We currently crash hard for using 32 or 64 bit mask registers without avx512bw.
llvm-svn: 358435
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a preparatory patch for D60093. This patch itself is NFC, but while preparing this I noticed and committed a small hoisting change in rL358419.
The basic structure of the new scheme is that we pass around the guard ("the using instruction"), and select an optimal insert point by examining operands at each construction point. This seems conceptually a bit cleaner to start with as it isolates the knowledge about insertion safety at the actual insertion point.
Note that the non-hoisting path is not actually used at the moment. That's not exercised until D60093 is rebased on this one.
Differential Revision: https://reviews.llvm.org/D60718
llvm-svn: 358434
|
|
|
|
|
|
| |
We were using C++11 features but the test needs to work in C++03 too.
llvm-svn: 358433
|
|
|
|
| |
llvm-svn: 358432
|
|
|
|
|
|
|
|
|
|
|
| |
Zexts can be treated like no-op casts when it comes to assessing whether their
removal affects debug info.
Reviewer: aprantl
Differential Revision: https://reviews.llvm.org/D60641
llvm-svn: 358431
|
|
|
|
| |
llvm-svn: 358430
|
|
|
|
| |
llvm-svn: 358429
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.
Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.
(relanding after revert, r358414)
Added DefaultOptions.clear() to reset().
Reviewers: alexfh, klimek
Reviewed By: klimek
Subscribers: kristina, MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59746
llvm-svn: 358428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pattern we replaced these with may be too hard to match as demonstrated by
PR41496 and PR41316.
This patch restores the intrinsics and then we can start focusing
on the optimizing the intrinsics.
I've mostly reverted the original patch that removed them. Though I modified
the avx512 intrinsics to not have masking built in.
Differential Revision: https://reviews.llvm.org/D60674
llvm-svn: 358427
|
|
|
|
| |
llvm-svn: 358425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of references
There are many STL algorithms (such as lexicographical_compare) that compare
values pointed to by iterators like so:
__comp(*it1, *it2);
When building with `_LIBCPP_DEBUG=0`, comparators are wrapped in `__debug_less`
which does some additional validation. But `__debug_less::operator()` takes
non-const references, so if the type of `*it1` is int, not int&, then the build
will fail.
This change adds a `const&` overload for `operator()` to fix the build.
Differential Revision: https://reviews.llvm.org/D60592
llvm-svn: 358423
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enable some of the existing size optimizations for cold code under PGO.
A ~5% code size saving in big internal app under PGO.
The way it gets BFI/PSI is discussed in the RFC thread
http://lists.llvm.org/pipermail/llvm-dev/2019-March/130894.html
Note it doesn't currently touch loop passes.
Reviewers: davidxl, eraman
Reviewed By: eraman
Subscribers: mgorny, javed.absar, smeenai, mehdi_amini, eraman, zzheng, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59514
llvm-svn: 358422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template args
A ConversionOperatorIdentifierNode has a TargetType which is read when
printing it, but if the ConversionOperatorIdentifierNode appears in a
template argument there's nothing that can provide the TargetType.
Normally the COIN is a symbol (leaf) name and takes its TargetType from the
symbol's type, but in a template argument context the COIN can only be
either a non-leaf name piece or a type, and must hence be invalid.
Similar to the COIN check in demangleDeclarator().
Found by oss-fuzz.
llvm-svn: 358421
|
|
|
|
| |
llvm-svn: 358420
|
|
|
|
|
|
| |
If we have multiple range checks which can be predicated, hoist the and of the results outside the loop. This minorly cleans up the resulting IR, but the main motivation is as a building block for D60093.
llvm-svn: 358419
|