Add support for combining a build vector to a shuffle.
When the build vector is of extracted elements from 2 vectors (vec1, vec2) where vec2 is 2 times smaller than vec1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305883 91177308-0d34-0410-b5e6-96231b3b80d8
MulOpsInlineThreshold option of SCEV is defaulted to 1000, which is inadequately high.
When constructing SCEVs of expressions like:
x1 = a * a
x2 = x1 * x1
x3 = x2 * x2
...
We actually have huge SCEVs with max allowed amount of operands inlined.
Such expressions are easy to get from unrolling of loops looking like
x = a
for (i = 0; i < n; i++)
x = x * x
Or more tricky cases where big powers are involved. If some non-linear analysis
tries to work with a SCEV that has 1000 operands, it may lead to excessively long
compilation. The attached test does not pass within 1 minute with default threshold.
This patch decreases its default value to 32, which looks much more reasonable if we
use analyzes with complexity O(N^2) or O(N^3) working with SCEV.
Differential Revision: https://reviews.llvm.org/D34397
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305882 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When we're building with XRay instrumentation, we use a trick that
preserves references from the function to a function sled index. This
index table lives in a separate section, and without this trick the
linker is free to garbage-collect this section and all the segments it
refers to. Until we're able to tell the linkers to preserve these
sections, we use this reference trick to keep around both the index and
the entries in the instrumentation map.
Before this change we emitted both a synthetic reference to the label in
the instrumentation map, and to the entry in the function map index.
This change removes the first synthetic reference and only emits one
synthetic reference to the index -- the index entry has the references
to the labels in the instrumentation map, so the linker will still
preserve those if the function itself is preserved.
This reduces the amount of synthetic references we emit from 16 bytes to
just 8 bytes in x86_64, and similarly to other platforms.
Reviewers: dblaikie
Subscribers: javed.absar, kpw, pelikan, llvm-commits
Differential Revision: https://reviews.llvm.org/D34340
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305880 91177308-0d34-0410-b5e6-96231b3b80d8
Right now areMemoryOpsAliased has an assertion justified as:
MMO1 should have a value due it comes from operation we'd like to use
as implicit null check.
assert(MMO1->getValue() && "MMO1 should have a Value!");
However, it is possible for that invariant to not be upheld in the
following situation (conceptually):
Null check %RAX
NotNullSucc:
%RAX = LEA %RSP, 16 // I0
%RDX = MOV64rm %RAX // I1
With the current code, we will have an early exit from
ImplicitNullChecks::isSuitableMemoryOp on I0 with SR_Unsuitable.
However, I1 will look plausible (since it loads from %RAX) and
will go ahead and call areMemoryOpsAliased(I1, I0). This will cause
us to fail the assert mentioned above since I1 does not load from an
IR level value and thus is allowed to have a non-Value base address.
The fix is to bail out earlier whenever we see an unsuitable
instruction overwrite PointerReg. This would guarantee that when we
call areMemoryOpsAliased, we're guaranteed to be looking at an
instruction that loads from or stores to an IR level value.
Original Patch Author: sanjoy
Reviewers: sanjoy, mkazantsev, reames
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34385
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305879 91177308-0d34-0410-b5e6-96231b3b80d8
We weren't actually checking for duplicated stores, as the condition
was always actually false. This was found by Coverity, and I have
no clue how to trigger this in real-world code (although I
tried for a bit).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305867 91177308-0d34-0410-b5e6-96231b3b80d8
We forgot to serialize these because llvm-readobj didn't dump them. They
are typically all zeros in an object file. The linker fills them in with
relocations before adding them to the PDB. Now we can properly round
trip these symbols through pdb2yaml -> yaml2pdb.
I made these fields optional with a zero default so that we can elide
them from our test cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305857 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r305852.
The testcase already exists but I moved it to the X86 directory on a
using a different machine and got confused...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305856 91177308-0d34-0410-b5e6-96231b3b80d8
The instruction it falls over on is an IMPLICT_DEF that also happens
to be the only instruction in its lexical scope. That LexicalScope has
never been created because its range is empty. This patch skips over
all meta-instructions instead of just DBG_VALUEs.
Thanks to David Blaikie for providing a testcase!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305853 91177308-0d34-0410-b5e6-96231b3b80d8
This is a workaround for large file writes. It has been witnessed that
write(2) failing with EINVAL (22) due to a large value (>2G). Thanks to
James Knight for the help with coming up with a sane test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305846 91177308-0d34-0410-b5e6-96231b3b80d8
In the object file, the section index and relative offset are typically
zero, so make these YAML fields optional with a default.
It looks like there may be more partially initialized symbol records,
but this should fix the msan bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305842 91177308-0d34-0410-b5e6-96231b3b80d8
This commit causes LLVM_USE_SANITIZER to now accept the "Leaks" option. This
will cause cmake to pass in -fsanitize=leak in all of the appropriate places.
I am making this change so that I can setup a linux bot that only detects
leaks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305839 91177308-0d34-0410-b5e6-96231b3b80d8
Before it was possible to partially fold use instructions
before the defs. After the xor is folded into a copy, the same
mov can end up in the fold list twice, so on the second attempt
it will fail expecting to see a register to fold.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305821 91177308-0d34-0410-b5e6-96231b3b80d8
There were certain fields that we didn't know how to write, as
well as various padding bytes that we would ignore. This leads
to garbage data in the PDB. While not strictly necessary, we
should initialize these bytes to something meaningful, as it
makes for easier binary comparison between PDBs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305819 91177308-0d34-0410-b5e6-96231b3b80d8
This does some improvements/cleanup to the recently introduced
scavengeRegisterBackwards() functionality:
- Rewrite findSurvivorBackwards algorithm to use the existing
LiveRegUnit::accumulateBackward() code. This also avoids the Available
and Candidates bitset and just need 1 LiveRegUnit instance
(= 1 bitset).
- Pick registers in allocation order instead of register number order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305817 91177308-0d34-0410-b5e6-96231b3b80d8
If the source was a copy of an undef register, this would
produce a read of an undefined register which is a verifier
error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305816 91177308-0d34-0410-b5e6-96231b3b80d8
This is patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
In this patch, Options.td was mainly changed in order to add value class
in Options.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305805 91177308-0d34-0410-b5e6-96231b3b80d8
There are a couple of potential improvements as seen in the IR and asm:
1. We're unnecessarily extending to a larger type to compare values.
2. The codegen for (select cond, 1, -1) could avoid a cmov.
(or we could change the order of the compares, so we have a select with 0 operand)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305802 91177308-0d34-0410-b5e6-96231b3b80d8
We were incorrectly sign extending into the high word (as you would for
SMULO) when legalizing UMULO in terms of a wider full multiplication.
Patch by James Duley.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305800 91177308-0d34-0410-b5e6-96231b3b80d8
These diffs were in the last version of the patch in D33342,
but I accidentally committed the previous rev.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305793 91177308-0d34-0410-b5e6-96231b3b80d8
We have a large portfolio of folds for and-of-icmps and or-of-icmps in InstSimplify and InstCombine,
but hardly anything for xor-of-icmps. Rather than trying to rethink and translate all of those folds,
we can use the truth table definition of xor:
X ^ Y --> (X | Y) & !(X & Y)
...to see if we can convert the xor to and/or and then use the existing folds.
http://rise4fun.com/Alive/J9v
Differential Revision: https://reviews.llvm.org/D33342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305792 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As part of this
* Emitted instructions now have named MachineInstr variables associated
with them. This isn't particularly important yet but it's a small step
towards multiple-insn emission.
* constrainSelectedInstRegOperands() is no longer hardcoded. It's now added
as the ConstrainOperandsToDefinitionAction() action. COPY_TO_REGCLASS uses
an alternate constraint mechanism ConstrainOperandToRegClassAction() which
supports arbitrary constraints such as that defined by COPY_TO_REGCLASS.
Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls, aditya_nandakumar
Reviewed By: ab
Subscribers: javed.absar, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D33590
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305791 91177308-0d34-0410-b5e6-96231b3b80d8
Target shuffle combining now supports the matching of INSERT_VECTOR_ELT/PINSRW/PINSRB for merging multiple insertions into shuffles/bitmasks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305788 91177308-0d34-0410-b5e6-96231b3b80d8
