| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
tool. Fix ar to do that.
Differential Revision: https://reviews.llvm.org/D43987
llvm-svn: 326734
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, llvm-commits, rnk
Reviewed By: zturner
Subscribers: majnemer
Differential Revision: https://reviews.llvm.org/D43639
llvm-svn: 326731
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
Summary:
Presently, InstCombiner::foldICmpWithCastAndCast() implicitly assumes that it is
only invoked with icmp instructions of integer type. If that assumption is broken,
and it is called with an icmp of vector type, then it fails (asserts/crashes).
This patch addresses the deficiency. It allows it to simplify
icmp (ptrtoint x), (ptrtoint/c) of vector type into a compare of the inputs,
much as is done when the type is integer.
Reviewers: apilipenko, fedor.sergeev, mkazantsev, anna
Reviewed By: anna
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44063
llvm-svn: 326730
|
| |
|
|
|
|
|
|
| |
This patch teaches getMinimumFPType to support shrinking a vector of ConstantFPs. This should improve our ability to combine vector fptrunc with fp binops.
Differential Revision: https://reviews.llvm.org/D43774
llvm-svn: 326729
|
| |
|
|
|
|
| |
NFC
llvm-svn: 326724
|
| |
|
|
|
|
|
|
|
| |
The error occurs when reading i16 elements (as in the testcase) from a v8i8
with a pattern of <0,2,4,6>. As all the data in the vector is accessed, the
operation is not a VUZP. The patch stops the pattern recognition of VUZP when
EXTRACT_VECTOR_ELT has a different element type than BUILD_VECTOR.
llvm-svn: 326722
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getCompare returns true, false or undef constants if the comparison can
be evaluated, or nullptr if it cannot. This is in line with what
ConstantExpr::getCompare returns. It also allows us to use
ConstantExpr::getCompare for comparing constants.
Reviewers: davide, mssimpso, dberlin, anna
Reviewed By: davide
Differential Revision: https://reviews.llvm.org/D43761
llvm-svn: 326720
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use the whole gammut of constant immediates available to set up a vector.
Instead of using, for example, `mov w0, #0xffff; dup v0.4s, w0`, which
transfers between register files, use the more efficient `movi v0.4s, #-1`
instead. Not limited to just a few values, but any immediate value that can
be encoded by all the variants of `FMOV`, `MOVI`, `MVNI`, thus eliminating
the need to there be patterns to optimize special cases.
Differential revision: https://reviews.llvm.org/D42133
llvm-svn: 326718
|
| |
|
|
| |
llvm-svn: 326715
|
| |
|
|
|
|
|
| |
As far as I can tell legalization of weird sizes for the
output type isn't implemented.
llvm-svn: 326714
|
| |
|
|
|
|
|
|
| |
These were just copies of the relevant fuzzer binary with (presumably)
meaningful suffixes, but accounted for more than 10% of my build
directory (> 8GB). Hard drive space is cheap, but not that cheap.
llvm-svn: 326710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use the new resolver interface more explicitly, and avoid traversing
all the initializers multiple times.
Add a test case for a pattern that was broken by an earlier version
of this change.
An additional change is that we now remove *all* template arguments
after resolving them.
Change-Id: I86c828c8cc84c18b052dfe0f64c0d5cbf3c4e13c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43652
llvm-svn: 326706
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This changes the syntax of !foreach so that the first "parameter" is
a new syntactic variable: !foreach(x, lst, expr) will define the
variable x within the scope of expr, and evaluation of the !foreach
will substitute elements of the given list (or dag) for x in expr.
Aside from leading to a nicer syntax, this allows more complex
expressions where x is deeply nested, or even constant expressions
in which x does not occur at all.
!foreach is currently not actually used anywhere in trunk, but I
plan to use it in the AMDGPU backend. If out-of-tree targets are
using it, they can adjust to the new syntax very easily.
Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits, tpr
Differential Revision: https://reviews.llvm.org/D43651
llvm-svn: 326705
|
| |
|
|
|
|
|
|
| |
dependent instruction selection.
Differential revision: https://reviews.llvm.org/D35267
llvm-svn: 326703
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
NAME has already worked for def in a multiclass, since the (protoype)
record including its NAME variable is created before parsing the
superclasses. Since defm's do not have an associated single record,
support for NAME has to be implemented differently here.
Original test cases provided by Artem Belevich (tra)
Change-Id: I933b74f328c0ff202e7dc23a35b78f3505760cc9
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43656
llvm-svn: 326700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We can discard initial blocks that do other work
We do not need to limit ourselves to just the first block in the chain.
Reviewers: courbet, davide
Reviewed By: courbet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44029
llvm-svn: 326698
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We now check relocations offsets are within range, and the relocation
index is valid.
Also updated tests which contained invalid Wasm files that were
previously not checked.
Differential Revision: https://reviews.llvm.org/D43684
llvm-svn: 326697
|
| |
|
|
|
|
|
|
|
|
| |
These instructions require that the two S registers are adjacent (but not the R
registers), because only the first register is included in the encoding, but we
were not checking this in the assembler.
Differential revision: https://reviews.llvm.org/D44084
llvm-svn: 326696
|
| |
|
|
|
|
|
|
|
|
|
| |
This is required in order to enable relocs to be validated
as they are read in.
Also update tests with new section ordering.
Differential Revision: https://reviews.llvm.org/D43940
llvm-svn: 326694
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44023
llvm-svn: 326692
|
| |
|
|
| |
llvm-svn: 326679
|
| |
|
|
|
|
| |
storing v2i1 and v4i1 constants.
llvm-svn: 326678
|
| |
|
|
|
|
|
|
| |
fix a crash if we are storing a bitcast of a constant.
Loading a constant into a k-register in AVX512 requires a bitcast from a scalar constant. In the test case here we have a k-register store that gets split into multiple parts of KNL. MergeConsecutiveStores sees each of these pieces as a consecutive store and looks through the bitcast to find the underly scalar constant. But when we went to create the combined store we didn't look through the same bitcast.
llvm-svn: 326677
|
| |
|
|
|
|
|
|
| |
Add tests for FIADD/FISUB/FISUBR/FIMUL/FIDIV/FIDIVR
Shows we have more FILD stack usage than necessary (arg load, spill, reload to x87)
llvm-svn: 326674
|
| |
|
|
| |
llvm-svn: 326670
|
| |
|
|
|
|
|
|
| |
legalization if AVX512DQ is not supported.
We were previously doing this with isel patterns. Moving it to op legalization gives us chance to see the required bitcast earlier. And it lets us remove some isel patterns.
llvm-svn: 326669
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`musttail` calls can't be naively splitted. The split blocks must
include not only the call instruction itself, but also (optional)
`bitcast` and `return` instructions that follow it.
Clone `bitcast` and `ret`, place them into the split blocks, and
remove the tail block when done.
Reviewers: junbuml, mcrosier, davidxl, davide, fhahn
Reviewed By: fhahn
Subscribers: JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D43729
llvm-svn: 326666
|
| |
|
|
| |
llvm-svn: 326661
|
| |
|
|
| |
llvm-svn: 326660
|
| |
|
|
|
|
|
| |
As shown in D44043, we may need this fold in the backend,
but it's also missing in the IR optimizer.
llvm-svn: 326659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused some links to fail with ThinLTO due to missing symbols as
well as causing some binaries to have failures at runtime. We're working
with the author to get a test case, but want to get the tree green
again.
Further, it appears to introduce a data race. While the test usage of
threads was disabled in r325361 & r325362, that isn't an acceptable fix.
I've reverted both of these as well. This code needs to be thread safe.
Test cases for this are already on the original commit thread.
llvm-svn: 326638
|
| |
|
|
|
|
|
|
|
|
|
|
| |
use a SCALAR_TO_VECTOR rather than a single element BUILD_VECTOR to convert back to a vector type.
X86 considers v1i1 a legal type under AVX512 and as such a truncate from a v1iX type to v1i1 can be turned into a scalar truncate plus a conversion to v1i1. We would much prefer a v1i1 SCALAR_TO_VECTOR over a one element BUILD_VECTOR.
During lowering we were detecting the v1i1 BUILD_VECTOR as a splat BUILD_VECTOR like we try to do for v2i1/v4i1/etc. In this case we create (select i1 splat_elt, v1i1 all-ones, v1i1 all-zeroes). That goes through some more legalization and we end up with a CMOV choosing between 0 and 1 in scalar and a scalar_to_vector.
Arguably we could detect the v1i1 BUILD_VECTOR and do this better in X86 target code. But just using a SCALAR_TO_VECTOR in legalization is much easier.
llvm-svn: 326637
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43989
llvm-svn: 326636
|
| |
|
|
|
|
|
|
|
|
|
| |
The fast/linear DAG scheduler doesn't lower DBG_VALUEs except for
function entry nodes.
Patch by Joshua Cranmer!
Differential Revision: https://reviews.llvm.org/D43028
llvm-svn: 326631
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The symbolizer was checking for .debug as a subdirectory of the
binary file itself, not of the directory containing the binary. This led to
a failure to find split debug info when it was contained in a .debug directory.
Reviewers: rnk, glider, zturner
Subscribers: llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D44025
llvm-svn: 326630
|
| |
|
|
| |
llvm-svn: 326627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements relaxation for RISCV in the MC layer.
The following relaxations are currently handled:
1) Relax C_BEQZ to BEQ and C_BNEZ to BNEZ in RISCV.
2) Relax and C_J $imm to JAL x0, $imm and CJAL to JAL ra, $imm.
Reviewers: asb, llvm-commits, efriedma
Reviewed By: asb
Subscribers: shiva0217
Differential Revision: https://reviews.llvm.org/D43055
llvm-svn: 326626
|
| |
|
|
|
|
|
|
|
|
|
| |
This cast was causing invalid signatures to be written
for libcall functions.
Add an MC test which includes a call to builtin memcpy.
Differential Revision: https://reviews.llvm.org/D44037
llvm-svn: 326618
|
| |
|
|
|
|
| |
I forgot to check in the updated test cases after the r326613 commit.
llvm-svn: 326616
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds back-end support for the anyregcc calling convention
for use with patchpoints.
Since all registers are considered call-saved with anyregcc
(except for 0 and 1 which may still be clobbered by PLT stubs
and the like), this required adding support for saving and
restoring vector registers in prologue/epilogue code for the
first time. This is not used by any other calling convention.
llvm-svn: 326612
|
| |
|
|
|
|
|
| |
This adds back-end support for the @llvm.experimental.stackmap and
@llvm.experimental.patchpoint intrinsics.
llvm-svn: 326611
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On SystemZ we need to provide a register save area of 160 bytes to
any called function. This size needs to be added when allocating
stack in the function prologue. However, it was not accounted for
as part of MachineFrameInfo::getStackSize(); instead the back-end
used a private routine getAllocatedStackSize().
This is OK for code-gen purposes, but it breaks other users of
the getStackSize() routine, in particular it breaks the recently-
added -stack-size-section feature.
Fix this by updating the main stack size tracked by common code
(in emitPrologue) instead of using the private routine.
No change in code generation intended.
llvm-svn: 326610
|
| |
|
|
|
|
|
|
| |
This adds support for specifying vector registers for use with inline
asm statements, either via the 'v' constraint or by explicit register
names (v0 ... v31).
llvm-svn: 326609
|
| |
|
|
|
|
|
|
|
|
| |
The code was checking that all of the instructions in the
sequence are 'fast', but that's not necessary. The final
multiply is all that we need to check (tests adjusted).
The fmul doesn't need to be fully 'fast' either, but that
can be another patch.
llvm-svn: 326608
|
| |
|
|
|
|
|
|
| |
This narrow fold was added with no motivation or test cases
a bit over 5 years ago. Removing a constant operand is a
good canonicalization? We should handle Y*2.0 too then?
llvm-svn: 326606
|
| |
|
|
| |
llvm-svn: 326599
|
| |
|
|
|
|
|
|
| |
These instructions are double-pumped, split into 2 128-bit ops and then passing through either FPU pipe.
Found while testing llvm-mca (D43951)
llvm-svn: 326597
|
| |
|
|
|
|
|
|
| |
Fixes PR36532
Differential Revision: https://reviews.llvm.org/D43960
llvm-svn: 326596
|
| |
|
|
|
|
|
|
|
|
| |
If we are only truncating bits from the extend we should be able to just use a smaller extend.
If we are truncating more than the extend we should be able to just use a fptrunc since the presense of the fpextend shouldn't affect rounding.
Differential Revision: https://reviews.llvm.org/D43970
llvm-svn: 326595
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For the x32 ABI, since the base pointer register (EBX) is a callee save register
it should be saved before use.
This fixes https://bugs.llvm.org/show_bug.cgi?id=36011
Differential Revision: https://reviews.llvm.org/D42358
Patch by Pratik Bhatu
llvm-svn: 326593
|