| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This will become necessary in some cases once D22296 lands.
llvm-svn: 289165
|
|
|
|
| |
llvm-svn: 289164
|
|
|
|
|
|
|
|
| |
This just hoists the check for declarations up a layer which allows
various sets used in the walk to be smaller. Also moves the relevant
comments to match, and catches a few other cleanups in this code.
llvm-svn: 289163
|
|
|
|
|
|
|
|
| |
Based on a patch by LemonBoy!
Differential Revision: https://reviews.llvm.org/D26581
llvm-svn: 289162
|
|
|
|
|
|
| |
This patch adds support for round tripping DWARF debug_aranges in and out of YAML.
llvm-svn: 289161
|
|
|
|
|
|
| |
Use warnings; other minor fixes (NFC).
llvm-svn: 289160
|
|
|
|
|
|
|
| |
Tagged parameter names with \a doxygen command to display parameters in italics.
Formatted comments to fit into 80 chars.
llvm-svn: 289159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes libc++'s tuple extension which allowed it to be
constructed from fewer initializers than elements; with the remaining
elements being default constructed. However the implicit version of
this extension breaks conforming code. For example:
int fun(std::string);
int fun(std::tuple<std::string, int>);
int x = fun("hello"); // ambigious
Because existing code may already depend on this extension it can be re-enabled
by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION.
Note that the explicit version of this extension is still supported,
although it's somewhat less useful than the implicit one.
llvm-svn: 289158
|
|
|
|
| |
llvm-svn: 289157
|
|
|
|
| |
llvm-svn: 289156
|
|
|
|
| |
llvm-svn: 289155
|
|
|
|
|
|
|
|
| |
Improved doxygen comments for fxsrintrin.h and mmintrin.h intrinsics by taagging parameter names with \a doxygen command to display parameters in italics.
Formatted comments to fit into 80 chars.
llvm-svn: 289154
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27587
llvm-svn: 289153
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of the output section data store commands
can only handle integer literals, but it should really handle arbitrary
expressions [1]. This commit fixes that.
[1] https://sourceware.org/binutils/docs-2.27/ld/Output-Section-Data.html#Output-Section-Data
Differential Revision: https://reviews.llvm.org/D27561
llvm-svn: 289152
|
|
|
|
| |
llvm-svn: 289151
|
|
|
|
|
|
|
| |
Supporting them properly is a reasonably complex chunk of work, so to allow bot
testing before then we should at least be able to fall back to DAG ISel.
llvm-svn: 289150
|
|
|
|
| |
llvm-svn: 289149
|