During type promotion, sometimes we convert negative an add with a
negative constant into a sub with a positive constant. The loop that
performs this transformation has two issues:
- it iterates over a set, causing non-determinism.
- it breaks, instead of continuing, when it finds the first
non-negative operand.
Differential Revision: https://reviews.llvm.org/D58452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354557 91177308-0d34-0410-b5e6-96231b3b80d8
Adds llvm-dwarfdump support for pretty printing Dwarf5 expressions ops
that reference a base type (right now only DW_OP_convert is added).
Includes verification to verify that the ops operand is actually a
DW_TAG_base_type DIE.
Differential Revision: https://reviews.llvm.org/D58442
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354552 91177308-0d34-0410-b5e6-96231b3b80d8
When we create fictive switch in preheader, we should take
care about MSSA and delete edge between old preheader and
header.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354547 91177308-0d34-0410-b5e6-96231b3b80d8
Previously if we couldn't derive a prototype for a "no-prototype"
function from C we would leave it as is:
void foo(...)
With this change we instead give is an empty signature and remove
the "no-prototype" attribute.
This fixes the current wasm waterfall test failure.
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58488
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354544 91177308-0d34-0410-b5e6-96231b3b80d8
is false.
Right now for inliner and partial inliner, we always pass the address of a
valid ORE object to getInlineCost even if RemarkEnabled is false because of
no -Rpass is specified. Since ComputeFullInlineCost will be set to true if
ORE is non-null in getInlineCost, this introduces the problem that in
getInlineCost we cannot return early even if we already know the cost is
definitely higher than the threshold. It is a general problem for compile
time.
This patch fixes that by pass nullptr as the ORE argument if RemarkEnabled is
false.
Differential Revision: https://reviews.llvm.org/D58399
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354542 91177308-0d34-0410-b5e6-96231b3b80d8
When we can't determine with certainty the signature of a function
import we pick the fist signature we find rather than error'ing out.
The resulting program might not do what is expected since we might pick
the wrong signature. However since undefined behavior in C to use the
same function with different signatures this seems better than refusing
to compile such programs.
Fixes PR40472
Differential Revision: https://reviews.llvm.org/D58304
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354523 91177308-0d34-0410-b5e6-96231b3b80d8
This change makes some basic type combinations for G_SHUFFLE_VECTOR legal, and
implements them with a very pessimistic TBL2 instruction in the selector.
For TBL2, support is also needed to generate constant pool entries and load from
them in order to materialize the mask register.
Currently supports <2 x s64> and <4 x s32> result types.
Differential Revision: https://reviews.llvm.org/D58466
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354521 91177308-0d34-0410-b5e6-96231b3b80d8
If the LHS has known zeros, then the RHS immediate mask might have been simplified to remove those bits.
This patch adds a call to computeKnownBits to get the known zeroes to handle that possibility. I left an early out to skip the call if all of the demanded bits are set in the mask.
Differential Revision: https://reviews.llvm.org/D58464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354514 91177308-0d34-0410-b5e6-96231b3b80d8
Second part of https://bugs.llvm.org/show_bug.cgi?id=40442.
This adds an extra UnrollVectorOverflowOp() method to SDAG, because
the general UnrollOverflowOp() method can't deal with multiple results.
Additionally we need to expand UMULO/SMULO during vector op
legalization, as it may result in unrolling, which may need additional
type legalization.
Differential Revision: https://reviews.llvm.org/D57997
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354513 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids depending on the peephole pass to do load folding.
Also adds some load folding for some insert_subvector patterns that use blend.
All of this was found by temporarily adding TB_NO_FORWARD to the blend immediate entries in the load folding tables.
I've added -disable-peephole to some of the affected tests from that experiment to ensure we're testing isel patterns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354511 91177308-0d34-0410-b5e6-96231b3b80d8
If the bit position has known zeros in it, then the AND immediate will likely be optimized to remove bits.
This can prevent GetDemandedBits from recognizing that the AND is unnecessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354498 91177308-0d34-0410-b5e6-96231b3b80d8
Every cycle, the Scheduler checks if instructions in the ReadySet can be issued
to the underlying pipelines. If an instruction cannot be issued because one or
more pipeline resources are unavailable, then field
Instruction::CriticalResourceMask is updated with the resource identifier of the
unavailable resources.
If an instruction cannot be promoted from the PendingSet to the ReadySet because
of a memory dependency, then field Instruction::CriticalMemDep is updated with
the identifier of the dependending memory instruction.
Bottleneck information is collected after every cycle for instructions that are
waiting to execute. The idea is to help identify causes of bottlenecks; this
information can be used in future to implement a bottleneck analysis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354490 91177308-0d34-0410-b5e6-96231b3b80d8
We currently bail if the target shuffle decodes to more than 2 input vectors, this is some initial cleanup that still has the limit but generalizes the opindices to an array that will be necessary when we drop the limit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354489 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a lookup table to speed up resource queries in the ResourceManager.
This patch also moves helper function 'getResourceStateIndex()' from
ResourceManager.cpp to Support.h, so that we can reuse that logic in the
SummaryView (and potentially other views in llvm-mca).
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354470 91177308-0d34-0410-b5e6-96231b3b80d8
The m_APFloat matcher does not work with anything but strict
splat vector constants, so we could miss these folds and then
trigger an assertion in instcombine:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13201
The previous attempt at this in rL354406 had a logic bug that
actually triggered a regression test failure, but I failed to
notice it the first time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354467 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a follow-up to r353988 where tryEvict was extended to take last
chance recoloring into account. Now we do the same thing for trySplit and
tryAssign.
Now we always pass a "FixedRegisters" argument to canEvictInterference and
tryEvict so it doesn't need to have a default value anymore.
The need for this was found long ago in an out-of-tree target.
Unfortunately I don't have a reproducer for an in-tree target.
Reviewers: qcolombet, rudkx
Reviewed By: qcolombet, rudkx
Subscribers: rudkx, MatzeB, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58376
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354439 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Inc and Dec were at one point slow on Intel CPUs due to their tendency to cause partial flag stalls on P6 derived CPU cores. This is because these instructions are defined to preserve the carry flag. This partial flag stall issue persisted until Sandy Bridge when flag merging was changed to be handled as a data dependency instead of as a stall until retirement. Sandy Bridge and later CPUs rename the C flag separately from OSPAZ so there is no flag merge needed on INC/DEC to preserve the C flag.
Given these improvements I don't know why INC/DEC was ever considered slow on Sandy Bridge. If anything they should have been disabled on the earlier CPUs instead.
Note after this patch, INC/DEC are still considered slow on Silvermont, Goldmont, Knights Landing and our generic "x86-64" CPU.
Reviewers: spatel, RKSimon, chandlerc
Reviewed By: chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D58412
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354436 91177308-0d34-0410-b5e6-96231b3b80d8
As this has broken the lto bootstrap build for 3 days and is
showing a significant regression on the Dither_benchmark results (from
the LLVM benchmark suite) -- specifically, on the
BENCHMARK_FLOYD_DITHER_128, BENCHMARK_FLOYD_DITHER_256, and
BENCHMARK_FLOYD_DITHER_512; the others are unchanged. These have
regressed by about 28% on Skylake, 34% on Haswell, and over 40% on
Sandybridge.
This reverts commit r353923.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354434 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Those pseudo-instructions are making load/store instructions able to
load/store from/to a symbol, and its always using PC-relative addressing
to generating a symbol address.
Reviewers: asb, apazos, rogfer01, jrtc27
Differential Revision: https://reviews.llvm.org/D50496
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354430 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Changes from using a total ordering of known sections to using a
dependency graph approach. This allows our tools to accept and process
binaries that are compliant with the spec and tool conventions that
would have been previously rejected. It also means our own tools can
do less work to enforce an artificially imposed ordering. Using a
general mechanism means fewer special cases and exceptions in the
ordering logic.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58312
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354426 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
- Make `ATOMIC_I`, `ATOMIC_NRI`, `AtomicLoad`, `AtomicStore` classes and
make other operations inherit from them
- Factor the common opcode prefix '0xfe' out from the opcodes into the
common class
- Reorder instructions in the order of increasing opcodes
Reviewers: tlively
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58338
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354421 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Fixed a bug in the routine in AsmParser that determines whether the
current instruction is a load or a store. Atomic instructions' prefixes
are not `atomic_` but `atomic.`, and all atomic instructions are also
memory instructions. Also fixed the printing format of atomic
instructions to match other memory instructions and added encoding tests
for atomic instructions.
Reviewers: aardappel, tlively
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58337
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354419 91177308-0d34-0410-b5e6-96231b3b80d8
Noticed these while doing a final sweep of the code to make sure I hadn't missed anything in my last couple of patches. The (minor) missed optimization was noticed because of the stylistic fix to avoid an overly specific cast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354412 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 058bb8351351d56d2a4e8a772570231f9e5305e5.
Forgot to update another test affected by this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354408 91177308-0d34-0410-b5e6-96231b3b80d8
Same case as for memset and memcpy, but this time for clobbering stores and loads. We still can't allow coercion to or from non-integrals, regardless of the transform.
Now that I'm done the whole little sequence, it seems apparent that we'd entirely missed reasoning about clobbers in the original GVN support for non-integral pointers.
My appologies, I thought we'd upstreamed all of this, but it turns out we were still carrying a downstream hack which hid all of these issues. My chanks to Cherry Zhang for helping debug.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354407 91177308-0d34-0410-b5e6-96231b3b80d8
Problem is very similiar to the one fixed for memsets in r354399, we try to coerce a value to non-integral type, and then crash while try to do so. Since we shouldn't be doing such coercions to start with, easy fix. From inspection, I see two other cases which look to be similiar and will follow up with most test cases and fixes if confirmed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354403 91177308-0d34-0410-b5e6-96231b3b80d8
GVN generally doesn't forward structs or array types, but it *will* forward vector types to non-vectors and vice versa. As demonstrated in tests, we need to inhibit the same set of transforms for vector of non-integral pointers as for non-integral pointers themselves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354401 91177308-0d34-0410-b5e6-96231b3b80d8
If we encountered a location where we tried to forward the value of a memset to a load of a non-integral pointer, we crashed. Such a forward is not legal in general, but we can forward null pointers. Test for both cases are included.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354399 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Rename MemoryIndex to InitFlags and implement logic for determining
data segment layout in ObjectYAML and MC. Also adds a "passive" flag
for the .section assembler directive although this cannot be assembled
yet because the assembler does not support data sections.
Reviewers: sbc100, aardappel, aheejin, dschuff
Subscribers: jgravelle-google, hiraditya, sunfish, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57938
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354397 91177308-0d34-0410-b5e6-96231b3b80d8
After r354178, these instruction expand to a sequence that uses an OR instruction. That OR clobbers EFLAGS so we need to state that to avoid accidentally using the clobbered flags.
Our tests show the bug, but I didn't notice because the SETcc instructions didn't move after r354178 since it used to be safe to do the fp->int conversion first.
We should probably convert this whole sequence to SelectionDAG instead of a custom inserter to avoid mistakes like this.
Fixes PR40779
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354395 91177308-0d34-0410-b5e6-96231b3b80d8
This is no-functional-change-intended, but that was also
true when it was part of rL354276, and I managed to lose
2 predicates for the fold with constant...causing much bot
distress. So this time I'm adding a couple of negative tests
to avoid that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354384 91177308-0d34-0410-b5e6-96231b3b80d8
Fangrui Song