| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
trying to support combininations for rvalue and lvalue references.
llvm-svn: 334379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR37427)
This patch started off much more general and ambitious, but it's been a nightmare
seeing all the ways x86 vector codegen can go wrong.
So the code is still structured to allow extending easily, but it's currently
limited in several ways:
1. Only handle cases with an extending load.
2. Only handle cases with a zero constant compare.
3. Ignore setcc with vector bitmask (SetCCWidth != 1) - so AVX512 should be unaffected.
The motivating case from PR37427:
https://bugs.llvm.org/show_bug.cgi?id=37427
...is the 1st test, and that shows the expected win - we eliminated the unnecessary
intermediate cast.
There's a clear regression in the last test (sgt_zero_fp_select) because we longer
recognize a 'SHRUNKBLEND' opportunity. I think that general problem is also present
in sgt_zero, so I'll try to fix that in a follow-up. We need to match a sign-bit
setcc from a sign-extended operand and remove it.
Differential Revision: https://reviews.llvm.org/D47330
llvm-svn: 334378
|
|
|
|
| |
llvm-svn: 334377
|
|
|
|
|
|
|
|
| |
(NFC).
This breaks some builders.
llvm-svn: 334376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I took some liberties and quoted fewer characters than before,
based on an article from MSDN which says that only certain characters
cause an arg to require quoting. This seems to be incorrect, though,
and worse it seems to be a difference in Windows version. The bot
that fails is Windows 7, and I can't reproduce the failure on Win
10. But it's definitely related to quoting and special characters,
because both tests that fail have a * in the argument, which is one
of the special characters that would cause an argument to be quoted
before but not any longer after the new patch.
Since I don't have Win 7, all I can do is just guess that I need to
restore the old quoting rules. So this patch does that in hopes that
it fixes the problem on Windows 7.
llvm-svn: 334375
|
|
|
|
|
|
| |
Those changes were suggested post-commit for D47463.
llvm-svn: 334374
|
|
|
|
|
|
|
| |
test/Transforms/InstCombine/AMDGPU/amdgcn-intrinsics.ll broke,
and i did not notice because i did not build that backend.
llvm-svn: 334373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We already do it for matching splat constants, but not just values.
Further improvements for non-matching splat constants, as noted in
https://reviews.llvm.org/D46760#1123713 will be needed,
but i'd prefer to do that as a follow-up.
https://bugs.llvm.org/show_bug.cgi?id=37603
https://rise4fun.com/Alive/cplX
https://rise4fun.com/Alive/0HF
Reviewers: spatel, craig.topper
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47981
llvm-svn: 334372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We already do it for splat constants, but not just values.
Also, undef cases are mostly non-functional.
https://bugs.llvm.org/show_bug.cgi?id=37603
https://rise4fun.com/Alive/cplX
Reviewers: spatel, craig.topper
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47980
llvm-svn: 334371
|
|
|
|
| |
llvm-svn: 334370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/usr/bin/env is recommended as a cross-platform way to find python. But:
- we're only using lldb on darwin, where we know python (or at least,
the xcrun-style shortcut) is in /usr/bin/
- the python interpreter in LLDB comes from /S/L/F:
$ otool -L Contents/SharedFrameworks/LLDB.framework/LLDB | grep Python
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
so when we use the lldb python module, it calls into the swig/python
support in the lldb framework, and if there's a mismatch between the
interpreter and the linked python, weird things occur.
In theory, I believe this should be done by:
- looking for the LLDB framework (llgdb.py does some of that)
- finding the binary inside the framework
- looking for the Python it was linked against (otool -L)
- finding the interpreter executable inside the Python.framework
But in practice, that's only different if we use a custom LLDB
framework/pythonpath when running these tests, and AFAIK nobody does
that right now, so the code would be dead anyway.
Don't pretend we can use any arbitrary python: just use the system one.
Differential Revision: https://reviews.llvm.org/D47967
llvm-svn: 334369
|
|
|
|
|
|
| |
avx512vl. Update existing tests for avx512vbmi2 to use target independent intrinsics.
llvm-svn: 334368
|
|
|
|
| |
llvm-svn: 334367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to implement expandload/compressstore builtins.
Summary: We've had these target independent intrinsics for at least a year and a half. Looks like they do exactly what we need here and the backend already supports them.
Reviewers: RKSimon, delena, spatel, GBuella
Reviewed By: RKSimon
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47693
llvm-svn: 334366
|
|
|
|
|
|
| |
clang.
llvm-svn: 334365
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Now -exec-step uses SB API instead of HandleCommand hack.
Reviewers: aprantl, clayborg, labath, stella.stamenova
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47838
llvm-svn: 334364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Running sanitized 32-bit x86 programs on glibc 2.27 crashes at startup, with:
ERROR: AddressSanitizer: SEGV on unknown address 0xf7a8a250 (pc 0xf7f807f4 bp 0xff969fc8 sp 0xff969f7c T16777215)
The signal is caused by a WRITE memory access.
#0 0xf7f807f3 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x127f3)
#1 0xf7a92599 (/lib/libasan.so.5+0x112599)
#2 0xf7a80737 (/lib/libasan.so.5+0x100737)
#3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f)
#4 0xf7f6eb49 (/lib/ld-linux.so.2+0xb49)
The problem is that glibc changed the calling convention for the GLIBC_PRIVATE
symbol that sanitizer uses (even when it should not, GLIBC_PRIVATE is exactly
for symbols that can change at any time, be removed etc.), see
https://sourceware.org/ml/libc-alpha/2017-08/msg00497.html
Fixes https://github.com/google/sanitizers/issues/954
Patch By: Jakub Jelinek
Reviewed By: vitalybuka, Lekensteyn
Differential Revison: https://reviews.llvm.org/D44623
llvm-svn: 334363
|
|
|
|
|
|
|
|
|
| |
We currently support them only in AArch64. The NEON Reference,
however, says they are 'ARMv7, ARMv8' intrinsics.
Differential Revision: https://reviews.llvm.org/D47446
llvm-svn: 334362
|
|
|
|
|
|
|
|
|
| |
We currently support them only in AArch64. The NEON Reference,
however, says they are 'ARMv7, ARMv8' intrinsics.
Differential Revision: https://reviews.llvm.org/D47447
llvm-svn: 334361
|
|
|
|
| |
llvm-svn: 334360
|
|
|
|
|
|
| |
builtins. Use select in IR instead.
llvm-svn: 334359
|
|
|
|
|
|
| |
intrinsics. Use a select in IR instead.
llvm-svn: 334358
|
|
|
|
| |
llvm-svn: 334357
|
|
|
|
|
|
|
|
|
| |
This reverts commit 65243b6d19143cb7a03f68df0169dcb63e8b4632.
Seems like it's not a flake. It might have something to do with
the '*' character being in a command line.
llvm-svn: 334356
|
|
|
|
|
|
|
|
|
| |
There were a few linux compilation failures, but other than that
I think this was just a flake that caused the tests to fail. I'm
going to resubmit and see if the failures go away, if not I'll
revert again.
llvm-svn: 334355
|
|
|
|
|
|
|
|
|
| |
This reverts commit 10d2e88e87150a35dc367ba30716189d2af26774.
This is causing some test failures for some reason, reverting
while I investigate.
llvm-svn: 334354
|
|
|
|
|
|
|
|
|
|
|
| |
This function was internal to Program.inc, but I've needed this
on several occasions when I've had to use CreateProcess without
llvm's sys::Execute functions. In doing so, I noticed that the
function was written using unsafe C-string access and was pretty
hard to understand / make sense of, so I've also re-written the
functions to use more modern LLVM constructs.
llvm-svn: 334353
|
|
|
|
|
|
|
|
|
|
| |
Symbols are cleaned up from the program state map when they go out of scope.
Memory regions are cleaned up when the corresponding object is destroyed, and
additionally in 'checkDeadSymbols' in case destructor modeling was incomplete.
Differential Revision: https://reviews.llvm.org/D47416
llvm-svn: 334352
|
|
|
|
| |
llvm-svn: 334351
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Now -exec-continue command uses SB API to resume target's process.
Reviewers: aprantl, clayborg, labath
Reviewed By: clayborg
Subscribers: apolyakov, labath, ki.stfu, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D47415
llvm-svn: 334350
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup for rL334347.
The fold is also valid for ashr.
https://rise4fun.com/Alive/0HF
https://bugs.llvm.org/show_bug.cgi?id=37603
https://reviews.llvm.org/D46760#1123713
https://rise4fun.com/Alive/cplX
llvm-svn: 334349
|
|
|
|
|
|
|
|
|
|
|
|
| |
This check will mark raw pointers to C++ standard library container internal
buffers 'released' when the objects themselves are destroyed. Such information
can be used by MallocChecker to warn about use-after-free problems.
In this first version, 'std::basic_string's are supported.
Differential Revision: https://reviews.llvm.org/D47135
llvm-svn: 334348
|
|
|
|
|
|
|
|
|
|
|
| |
We already do it for splat constants, but not just values.
Also, undef cases are mostly non-functional.
https://bugs.llvm.org/show_bug.cgi?id=37603
https://reviews.llvm.org/D46760#1123713
https://rise4fun.com/Alive/cplX
llvm-svn: 334347
|
|
|
|
|
|
|
|
|
|
| |
We already do it for splat constants, but not just values.
Also, undef cases are mostly non-functional.
https://bugs.llvm.org/show_bug.cgi?id=37603
https://rise4fun.com/Alive/cplX
llvm-svn: 334346
|
|
|
|
|
|
|
|
| |
The separate initializeEnvironment function was sort of
useless since r217071.
ARM did this move already with r273556.
llvm-svn: 334345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a recommit of r333506, which was reverted in r333518.
The original commit message is below.
In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
generate crash if memory cannot be allocated, such behavior facilitates
handling of out of memory errors on Windows.
If the result of *alloc function were checked for success, the function was
not replaced with the safe variant. In these cases the calling function made
the error handling, like:
T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T)));
if (NewElts == nullptr)
report_bad_alloc_error("Allocation of SmallVector element failed.");
Actually knowledge about the function where OOM occurred is useless. Moreover
having a single entry point for OOM handling is convenient for investigation
of memory problems. This change removes custom OOM errors handling and
replaces them with calls to functions `llvm::safe_*alloc`.
Declarations of `safe_*alloc` are moved to a separate include file, to avoid
cyclic dependency in SmallVector.h
Differential Revision: https://reviews.llvm.org/D47440
llvm-svn: 334344
|
|
|
|
|
|
|
|
| |
SmallSet forwards to SmallPtrSet for pointer types. SmallPtrSet supports iteration, but a normal SmallSet doesn't. So if it wasn't for the forwarding, this wouldn't work.
These places were found by hiding the begin/end methods in the SmallSet forwarding
llvm-svn: 334343
|
|
|
|
| |
llvm-svn: 334342
|
|
|
|
| |
llvm-svn: 334341
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Switch to aligned_alloc and posix_memalign tests in sanitizer_common
and delete the MSan-specific ones.
Reviewers: vitalybuka
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47968
llvm-svn: 334340
|
|
|
|
|
|
|
|
| |
SmallSet forwards to SmallPtrSet for pointer types. SmallPtrSet supports iteration, but a normal SmallSet doesn't. So if it wasn't for the forwarding, this wouldn't work.
These places were found by hiding the begin/end methods in the SmallSet forwarding.
llvm-svn: 334339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Following up on and complementing D44404.
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, not stack, no details, not too
helpful nor informative. To improve the situation, detailed and
structured errors were defined and reported under the appropriate conditions.
Reviewers: eugenis
Subscribers: srhines, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47793
llvm-svn: 334338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SparseVector with BitVector. NFC
Summary: Generating X86GenRegisterInfo.inc and AArch64GenRegisterInfo.inc is 8-9% faster on my build.
Reviewers: bogner, javed.absar
Reviewed By: bogner
Subscribers: llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D47907
llvm-svn: 334337
|
|
|
|
|
|
| |
This should have been removed in r334333.
llvm-svn: 334336
|
|
|
|
| |
llvm-svn: 334335
|
|
|
|
|
|
|
|
| |
There are many masked intrinsics that just wrap a select around a legacy intrinsic from a pre-avx512 instruciton set. If that intrinsic is implemented as a macro, nothing prevents it from being used when only the older feature was enabled. This likely generates very poor code since we don't have a good way to convert from the scalar masked type used by the intrinsic into a vector control for a legacy blend instruction. If we even have a blend instruction to use.
By adding a feature to the select builtins we can prevent and diagnose misuse of these intrinsics.
llvm-svn: 334334
|
|
|
|
|
|
|
| |
As far as I can tell, this code has always been guarded by `#if 0`. If
this is useful code, it can be added back.
llvm-svn: 334333
|
|
|
|
|
|
| |
Use %env_tool_ops instead of %tool_options.
llvm-svn: 334332
|
|
|
|
|
|
|
|
|
|
| |
others.
I'd like to make the select builtins require an avx512f, avx512bw, or avx512vl fature to match what is normally required to get masking. Truncate is special in that there are instructions with a 128/256-bit masked result even without avx512vl.
By using special buitlins we can emit a select without using the 128/256-bit select builtins.
llvm-svn: 334331
|
|
|
|
|
|
|
|
| |
I'm looking into making the select builtins require avx512f, avx512bw, or avx512vl since masking operations generally require those features.
The extract builtins are funny because the 512-bit versions return a 128 or 256 bit vector with masking even when avx512vl is not supported.
llvm-svn: 334330
|