Before this patch simplified SCEV expressions for PHI nodes were only returned
the very first time getSCEV() was called, but later calls to getSCEV always
returned the non-simplified value, which had "temporarily" been stored in the
ValueExprMap, but was never removed and consequently blocked the caching of the
simplified PHI expression.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261485 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
- Rename `"skylake"` == SkylakeServerProc to `"skylake-avx512"`
- Change `"skylake"` to denote SkylakeClientProc
- Fix the detection of cpu family 6 and model 94 to be
SkylakeClientProc instead of SkylakeServerProc
- Remove the `"cnl"` for CannonLake
Reviewers: craig.topper, delena
Subscribers: zansari, echristo, qcolombet, RKSimon, spatel, DavidKreitzer, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17090
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261482 91177308-0d34-0410-b5e6-96231b3b80d8
This is inspired by PR24804 -- had this assert been there before,
isolating the root cause for PR24804 would have been far easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261481 91177308-0d34-0410-b5e6-96231b3b80d8
r261457 handles CopyToReg nodes with flag results in LowerCopyToReg, which was causing the SelectionDAGNodes assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261479 91177308-0d34-0410-b5e6-96231b3b80d8
Add a common parent `ConstantData` to the constants that have no
operands. These are guaranteed to represent abstract data that is in no
way tied to a specific Module.
This is a good cleanup on its own. It also makes it simpler to disallow
RAUW (and factor away use-lists) on these constants in the future. (I
have some experimental patches that make RAUW illegal on ConstantData,
and they seem to catch a bunch of bugs...)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261464 91177308-0d34-0410-b5e6-96231b3b80d8
COFF doesn't have sections with mergeable contents. Instead, each
constant pool entry ends up in a COMDAT section. The linker, when
choosing between COMDAT sections, doesn't choose the max alignment of
the two sections. You just get whatever alignment was on the section.
If one constant needed a higher alignment in one object file from
another one, then we will get into trouble if the linker chooses the
lower alignment one.
Instead, lets promote the alignment of the constant pool entry to make
sure we don't use an under aligned constant with an instruction which
assumed otherwise.
This fixes PR26680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261462 91177308-0d34-0410-b5e6-96231b3b80d8
The stack pointer is bumped when there is a frame pointer or when there
are static-size objects, but was only getting written back when there
were static-size objects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261453 91177308-0d34-0410-b5e6-96231b3b80d8
TailDuplicate can run on either on SSA code or non-SSA code, as indicated to
it by MRI->isSSA() ("PreRegAlloc" here). TailDuplicate does extra work to
preserve SSA invariants when it duplicates code. This patch makes it skip
some of this extra work in the case where the code is not in SSA form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261450 91177308-0d34-0410-b5e6-96231b3b80d8
The patch has a necessary call to a function inside an assert. Which is fine
when you have asserts turned on. Not so much when they're off. Sorry about
the regression.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261447 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to review:
http://reviews.llvm.org/D17294
It ensures that whatever block we are emitting the prologue/epilogue into, we
have the necessary scratch registers. It takes away the hard-coded register
numbers for use as scratch registers as registers that are guaranteed to be
available in the function prologue/epilogue are not guaranteed to be available
within the function body. Since we shrink-wrap, the prologue/epilogue may end
up in the function body.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261441 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on PR24580, this patch adds some (more to come) initial fast-isel codegen tests to match the IR generated in clang/test/CodeGen/sse41-builtins.c
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261438 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed a bug introduced by D16683 when a binary shuffle is simplified to a unary shuffle (with undef/zero sentinel mask indices) - if this resulted in only the second input being used combineX86ShuffleChain failed to take this into account and still referenced the first input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261434 91177308-0d34-0410-b5e6-96231b3b80d8
First small step towards fixing PR26667 - we need to ensure that combineX86ShuffleChain only gets called with a valid shuffle input node (a similar issue was found in D17041).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261433 91177308-0d34-0410-b5e6-96231b3b80d8
the algorithm easily degrades into quadratic memory and time complexity.
The easiest example is a long chain of BBs that don't otherwise use a
location. The caching will add an entry for every intermediate block and
limiting the number of results doesn't help as no results are produced
until a definition is found.
Introduce a limit similar to the existing instructions-per-block limit.
This limit counts the total number of blocks checked. If the limit is
reached, entries are considered unknown. The initial value is 1000,
which avoids regressions for normal sized functions while still
limiting edge cases to reasnable memory consumption and execution time.
Differential Revision: http://reviews.llvm.org/D16123
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261430 91177308-0d34-0410-b5e6-96231b3b80d8
No functional change intended. Copying small (<= 64 bits) APInts isn't
expensive but bloats code by generating the slow path everywhere. Moving
doesn't care about the size of the value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261426 91177308-0d34-0410-b5e6-96231b3b80d8
This has no observable behavior change, it just makes the state
insertion pass look a little more like normal passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261420 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids unnecessarily passing them around when calling helper
functions. It may also be slightly faster to call clear() on the
datastructures instead of freshly initializing them for each block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261407 91177308-0d34-0410-b5e6-96231b3b80d8
tests over to exercise this code.
This uncovered a few missing bits here and there in the analysis, but
nothing interesting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261404 91177308-0d34-0410-b5e6-96231b3b80d8
it to actually test the new pass manager AA wiring.
This patch was extracted from the (somewhat too large) D12357 and
rebosed on top of the slightly different design of the new pass manager
AA wiring that I just landed. With this we can start testing the AA in
a thorough way with the new pass manager.
Some minor cleanups to the code in the pass was necessitated here, but
otherwise it is a very minimal change.
Differential Revision: http://reviews.llvm.org/D17372
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261403 91177308-0d34-0410-b5e6-96231b3b80d8
