| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 289215
|
|
|
|
|
|
| |
Part of the work for PR31323 - add extra asserts checking that the input vectors are of consistent type and result in the correct number of vector elements.
llvm-svn: 289214
|
|
|
|
| |
llvm-svn: 289213
|
|
|
|
| |
llvm-svn: 289212
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jingham
Subscribers: jaydeep, bhushan, slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D27124
llvm-svn: 289211
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, labath, zturner
Subscribers: jaydeep, bhushan, slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D27085
llvm-svn: 289210
|
|
|
|
|
|
|
|
|
|
|
|
| |
qprocessInfo packet.
Reviewers: jaydeep, bhushan, clayborg
Subscribers: slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D26542
llvm-svn: 289209
|
|
|
|
| |
llvm-svn: 289208
|
|
|
|
|
|
|
| |
The StringPool entries are destroyed with the allocator, the string pool
itself is not.
llvm-svn: 289207
|
|
|
|
| |
llvm-svn: 289206
|
|
|
|
| |
llvm-svn: 289205
|
|
|
|
| |
llvm-svn: 289204
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D27615
llvm-svn: 289203
|
|
|
|
|
|
| |
stabilize the test.
llvm-svn: 289202
|
|
|
|
|
|
| |
This fixes the build.
llvm-svn: 289201
|
|
|
|
|
|
|
|
|
|
| |
Adds support for bitcasting a little endian 'small element' vector to 'large element' scalar/vector (e.g. v16i8 to v4i32 or v2i32 to i64), which is required for PR30845. We extract the knownbits for each 'small element' part and concatenate the results together.
We can add support for big endian and 'large element' scalar/vector to 'small element' vector bitcasting once we have test cases for them.
Differential Revision: https://reviews.llvm.org/D27129
llvm-svn: 289200
|
|
|
|
|
|
|
|
|
| |
This test links against liblldb, so it can only run when the target arch is the
same arch as liblldb. We already have a decorator for that, so apply it.
While I'm in there, also mark the test as debug-info independent.
llvm-svn: 289199
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The i386 glibc ld.so expects the .got.slot entry that is relocated by a
R_386_IRELATIVE relocation to point directly at the ifunc resolver and
not the address of the PLT entry + 6 (thus entering the lazy resolver).
This is also the case for ARM and I suspect it is because these use REL
relocations and can't use the addend field to store the address of the
ifunc resolver. If the lazy resolver is used we get an error message
stating that only R_386_JUMP_SLOT is supported.
As ARM and i386 share the same code, I've removed the ARM specific test
and added a writeIgotPlt() function that by default calls writeGotPlt().
ARM and i386 override this to write the address of the ifunc resolver.
Differential Revision: https://reviews.llvm.org/D27581
llvm-svn: 289198
|
|
|
|
| |
llvm-svn: 289197
|
|
|
|
| |
llvm-svn: 289196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes where the C++ ABI headers are put during the build. Previously
they were put in the top level include directory (not the libc++ header directory).
However that just polutes the top level directory. Instead this patch creates a special
directory to put them in. The reason they can't be put under c++/v1 until after the build
is because libc++ uses the in-source headers, so we can't add the include path of the libc++
headers in the object dir.
Additionally this patch teaches the test suite how to find the ABI headers,
and adds a demangling utility to help debug tests with.
llvm-svn: 289195
|
|
|
|
|
|
|
|
| |
This reverts commit r288916 as it is currently causing a crasher in
Halide. Reproducer on llvm.org/PR31323. While it might be that halide is
generating invalid IR, llc shouldn't crash.
llvm-svn: 289194
|
|
|
|
|
|
|
|
|
|
| |
allow (scalar_to_vector (loadf32/load64)) instead of anything that sse_load_f32/f64 can match.
sse_load_f32/f64 can also match loads that are zero extended to vectors. We shouldn't match that because we wouldn't be able to get the instruction to zero the upper bits like the intrinsic semantics would require for such a case.
There is a test case that does depend on this behavior.
llvm-svn: 289193
|
|
|
|
|
|
|
|
|
|
| |
We could previously select an integer which would hit an assertion error
in pseudo expansion.
The new type will also generate the appropriate fixups if needed, which
wasn't done beforehand.
llvm-svn: 289192
|
|
|
|
|
|
| |
This adds MIR tests for 24 pseudo instructions.
llvm-svn: 289191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Scalar intrinsics have specific semantics about the which input's upper bits are passed through to the output. The same input is also supposed to be the input we use for the lower element when the mask bit is 0 in a masked operation. We aren't currently keeping these semantics with instruction selection.
This patch corrects this by introducing new scalar FMA ISD nodes that indicate whether operand 1(one of the multiply inputs) or operand 3(the additon/subtraction input) should pass thru its upper bits.
We use this information to select 213/132 form for the operand 1 version and the 231 form for the operand 3 version.
We also use this information to suppress combining FNEG operations on the passthru input since semantically the passthru bits aren't negated. This is stronger than the earlier check added for a user being SELECTS so we can remove that.
This fixes PR30913.
Reviewers: delena, zvi, v_klochkov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27144
llvm-svn: 289190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were selecting directly to the VOP2 form instead
of VOP3 like the i32 instructions. Fixes regressions in
future commits where an immediate isn't folded because it was
initially used for the second operand.
Because uniform 16-bit operations are promoted to i32, it's
difficult to get a simple testcase where this matters. Fold
failures in SIFoldOperands here tend to be hidden by commute
and fold in SIShrinkInstructions.
llvm-svn: 289189
|
|
|
|
| |
llvm-svn: 289188
|
|
|
|
|
|
| |
with a configure-time check for lseek64.
llvm-svn: 289187
|
|
|
|
| |
llvm-svn: 289186
|
|
|
|
| |
llvm-svn: 289185
|
|
|
|
| |
llvm-svn: 289184
|
|
|
|
|
|
|
|
|
| |
I don't think the data I add to a TPI stream in this patch is correct,
but at least it can be displayed using llvm-pdbdump. Until I add more
streams to a PDB file, I'm not able to know whether the data will be
accepted by MSVC tools or not.
llvm-svn: 289183
|
|
|
|
|
|
| |
Add a comment while here.
llvm-svn: 289182
|
|
|
|
|
|
|
|
|
| |
Allow darwin to provide additional definitions and implementation
specifc values for tgmath.h on Apple platforms.
rdar://problem/19019845
llvm-svn: 289181
|
|
|
|
|
|
|
|
| |
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D27605
llvm-svn: 289180
|
|
|
|
|
|
|
|
| |
This patch is to implement sema and parsing for 'teams distribute parallel for' pragma.
Differential Revision: https://reviews.llvm.org/D27345
llvm-svn: 289179
|
|
|
|
| |
llvm-svn: 289178
|
|
|
|
| |
llvm-svn: 289177
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common workflow with module reproducers involves deleting the
module cache before running the script. This happens because leftovers
from the crash are present in the cache and could trigger unrelated and
confusing errors, misleading from the initial reproduction intent.
Change this to point to a clean path but leave the leftovers untouched.
rdar://problem/28655070
llvm-svn: 289176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivating example is:
extern int patatino;
int goo() {
int x = 0;
for (int i = 0; i < 1000000; ++i) {
x *= patatino;
}
return x;
}
Currently SCCP will not realize that this function returns always zero,
therefore will try to unroll and vectorize the loop at -O3 producing an
awful lot of (useless) code. With this change, it will just produce:
0000000000000000 <g>:
xor %eax,%eax
retq
llvm-svn: 289175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When -fmodules is on, the reproducer invocation currently leave paths
for include-like flags as is. If the path is relative, the reproducer
doesn't know how to access that file during reproduction time because
the VFS cannot reason about relative paths.
Expand relative paths to absolute ones when creating the reproducer
command line. This allows, for example, the reproducer to work for
crashes while building clang with modules; this wasn't possible before
because building clang requires using relative inc dir from within the
build directory.
rdar://problem/28655070
llvm-svn: 289174
|
|
|
|
| |
llvm-svn: 289173
|
|
|
|
|
|
| |
integer test.
llvm-svn: 289172
|
|
|
|
| |
llvm-svn: 289171
|
|
|
|
| |
llvm-svn: 289170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crashing LLDB.
I found the race condition in:
ScriptInterpreter *CommandInterpreter::GetScriptInterpreter(bool can_create);
More than one "ScriptInterpreter *" was being returned due to the race which caused any clients with the first one to now be pointing to freed memory and we would quickly crash.
Added a test to catch this so we don't regress.
<rdar://problem/28356584>
llvm-svn: 289169
|
|
|
|
|
|
|
| |
Hopefully these will all disappear in the future once we move
to formatv.
llvm-svn: 289168
|
|
|
|
|
|
|
|
|
| |
Rewriter tests rewrite Objective-C++ to C++, and then compile the
result. The rewritten result sometimes doesn't work with C++11. As
we want to allow Clang's default dialect to become C++11, we need to
make sure the tests will still pass.
llvm-svn: 289167
|
|
|
|
|
|
| |
(https://github.com/google/sanitizers/issues/722). This is a first experimental variant that needs some more testing, thus not yet adding a lit test (but there are unit tests).
llvm-svn: 289166
|