| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41617
llvm-svn: 322500
|
|
|
|
| |
llvm-svn: 322499
|
|
|
|
|
|
|
| |
The old implementation was not always correct. The new one recognizes
more shuffles that match specific instructions.
llvm-svn: 322498
|
|
|
|
|
|
|
|
|
|
| |
In some cases we do not copy implicit defs from pseudo to real
VOP instructions. It has no visible impact at the moment thus no
tests are affected or added.
Differential Revision: https://reviews.llvm.org/D41783
llvm-svn: 322496
|
|
|
|
| |
llvm-svn: 322495
|
|
|
|
| |
llvm-svn: 322491
|
|
|
|
|
|
| |
This fixes the FIXME introduced in r315327.
llvm-svn: 322490
|
|
|
|
|
|
|
|
|
|
| |
Since a load and test instruction treat its operands as signed, it can only
replace a logical compare for EQ/NE uses.
Review: Ulrich Weigand
https://bugs.llvm.org/show_bug.cgi?id=35662
llvm-svn: 322488
|
|
|
|
| |
llvm-svn: 322487
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is similar to https://reviews.llvm.org/D41983.
Reviewers: gchatelet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42069
llvm-svn: 322486
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40067
llvm-svn: 322485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Due to missing parentheses.
This is similar to https://reviews.llvm.org/D41983.
Reviewers: gchatelet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42062
llvm-svn: 322483
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: fhahn, rengolin, t.p.northover, echristo, olista01, samparker
Reviewed By: fhahn, samparker
Subscribers: samparker, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D41899
llvm-svn: 322481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For example, VSQRTSDZr and VSQRTSSZr were missing the predicate.
Also fix braces indentation and braces for consistency.
Reviewers: craig.topper, RKSimon
Suscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41983
llvm-svn: 322478
|
|
|
|
|
|
|
| |
all callers have been switched the the Writable version (which does not
require const_casting to be useful).
llvm-svn: 322475
|
|
|
|
|
|
|
| |
This reverts commit r322085. Internal PPC testing is still showing the
same symptoms as when this patch landed the last time.
llvm-svn: 322474
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from a trunc.
Summary:
This method is supposed to be called for IVs that have casts in their use-def
chains that are completely ignored after vectorization under PSE. However, for
truncates of such IVs the same InductionDescriptor is used during
creation/widening of both original IV based on PHINode and new IV based on
TruncInst.
This leads to unintended second call to recordVectorLoopValueForInductionCast
with a VectorLoopVal set to the newly created IV for a trunc and causes an
assert due to attempt to store new information for already existing entry in the
map. This is wrong and should not be done.
Fixes PR35773.
Reviewers: dorit, Ayal, mssimpso
Reviewed By: dorit
Subscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41913
llvm-svn: 322473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bits isa sets.<NFC>
NFC.
Adding MC regressions tests to cover the AVX512F_512 isa sets both 32 and 64 bit.
This patch is part of a larger task to cover MC encoding of all X86 ISA Sets.
started in revision: https://reviews.llvm.org/D39952
Reviewers: zvi, craig.topper, RKSimon, AndreiGrischenko
Differential Revision: https://reviews.llvm.org/D41172
Change-Id: I46aa33dd967d63d33f67d1988ad42d8df2081e39
llvm-svn: 322471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR35899.
Debug info intrinsics shouldn't affect code generation so ignore them
in GlobalsAA.
Reviewers: hfinkel, aprantl
Reviewed By: aprantl
Subscribers: aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D41984
llvm-svn: 322470
|
|
|
|
| |
llvm-svn: 322468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An alternative (and probably better) fix would be that of
making `Scale` an APInt, and there's a patch floating around
to do this. As we're still discussing it, at least stop crashing
in the meanwhile (added bonus, we now have a regression test for
this situation).
Fixes PR35843.
Thanks to Eli for suggesting the fix and Simon for reporting and
reducing the bug.
llvm-svn: 322467
|
|
|
|
| |
llvm-svn: 322466
|
|
|
|
|
|
| |
The test was added ages ago, but we didn't comment where it came from.
llvm-svn: 322465
|
|
|
|
| |
llvm-svn: 322464
|
|
|
|
| |
llvm-svn: 322463
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scalar operations
Summary: This patch changes the kunpck intrinsic autoupgrade to use vXi1 shufflevector operations to perform vector extracts and concats. This more closely matches the definition of the kunpck instructions. Currently we rely on a DAG combine to turn the scalar shift/and/or code into a concat vectors operation. By doing it in the IR we get this for free.
Reviewers: spatel, RKSimon, zvi, jina.nahias
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42018
llvm-svn: 322462
|
|
|
|
| |
llvm-svn: 322460
|
|
|
|
| |
llvm-svn: 322459
|
|
|
|
|
|
| |
Shows a missed opportunity to remove a unnecessary move compared to 31 shuffle mask.
llvm-svn: 322458
|
|
|
|
| |
llvm-svn: 322457
|
|
|
|
| |
llvm-svn: 322456
|
|
|
|
|
|
| |
types have the same number of elements.
llvm-svn: 322455
|
|
|
|
|
|
|
|
| |
We have to take special care to avoid the cases where the result of the truncate would be padded with zero elements.
Ideally we'd just use ISD::TRUNCATE for these cases instead.
llvm-svn: 322454
|
|
|
|
|
|
|
|
| |
Extend vXi1 conditions of vXi8/vXi16 selects even before type legalization gets a chance to split wide vectors. Previously we would only extend 128 and 256 bit vectors. But if we start with a 512 bit vector or wider that needs to be split we wouldn't extend until after the split had taken place. By extending early we improve the results of type legalization.
Don't widen condition of 128/256 bit vXi16/vXi8 selects when we have BWI but not VLX. We can still use a mask register by widening the select to 512-bits instead. This is similar to what we do for compares already.
llvm-svn: 322450
|
|
|
|
|
|
|
|
| |
additional test cases.
Additional test cases cover selects with i16/i8 conditions that are only 128/256-bits wide, but the compares are 512-bits wide and can only produce k-registers. We should be able to artificially widen the selects to avoid moving the k-register to an xmm/ymm register.
llvm-svn: 322449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to the existing match as part of a loop-reduction, add a
straightforward pattern match for DAG-contained patterns.
Reviewers: RKSimon, craig.topper
Subscribers: llvm-commits
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D41811
llvm-svn: 322446
|
|
|
|
| |
llvm-svn: 322444
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends rL322327 to handle the pointer cast and should solve:
https://bugs.llvm.org/show_bug.cgi?id=35790
Name: or_eq_zero
%isnull = icmp eq i64* %p, null
%x = ptrtoint i64* %p to i64
%somebits = and i64 %x, %y
%somebits_are_zero = icmp eq i64 %somebits, 0
%or = or i1 %somebits_are_zero, %isnull
=>
%or = %somebits_are_zero
Name: and_ne_zero
%isnotnull = icmp ne i64* %p, null
%x = ptrtoint i64* %p to i64
%somebits = and i64 %x, %y
%somebits_are_not_zero = icmp ne i64 %somebits, 0
%and = and i1 %somebits_are_not_zero, %isnotnull
=>
%and = %somebits_are_not_zero
https://rise4fun.com/Alive/CQ3
llvm-svn: 322439
|
|
|
|
|
|
| |
As discussed in D41908
llvm-svn: 322436
|
|
|
|
|
|
| |
Improve coverage of D41811
llvm-svn: 322434
|
|
|
|
|
|
|
|
| |
have AVX512 but not BWI.
This avoids having the result type stick around until lowering where we have to extend the setcc and insert a truncate. If we get the types converted early we can do more to optimize it.
llvm-svn: 322432
|
|
|
|
| |
llvm-svn: 322430
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Necessary to achieve consistent test results.
Reviewers: kcc, alekseyshl
Subscribers: kubamracek, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D42023
llvm-svn: 322429
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*Mostly* NFC. Still updating the test though just for completeness.
This moves the hasAddressTaken check to MachineOutliner.cpp and replaces it
with a per-basic block test rather than a per-function test. The old test was
too conservative and was preventing functions in C programs from being
outlined even though they were safe to outline.
This was mostly a problem in C sources.
llvm-svn: 322425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A recent change
321556: AMDGPU: Remove mayLoad/hasSideEffects from MIMG stores
can allow the machine instruction scheduler to move an image store past
an image load using the same descriptor.
V2: Fixed by marking image ops as mayAlias and isAliased. This may be
overly conservative, and we may need to revisit.
V3: Reverted test change done on 321556.
Reviewers: arsenm, nhaehnle, dstuttard
Subscribers: llvm-commits, t-tye, yaxunl, wdng, kzhuravl
Differential Revision: https://reviews.llvm.org/D41969
llvm-svn: 322419
|
|
|
|
| |
llvm-svn: 322411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ELF specification says that all ELF data structures are aligned to
their natural alignments both in memory and file. That means when we
access mmap'ed ELF files, we could assume that all data structures are
aligned properly.
However, in reality, we assume that the data structures are aligned only
to two bytes because .a files only guarantee that their member files are
aligned to two bytes in archive files. So the data access is already
unaligned.
This patch relaxes the alignment requirement even more, so that we
accept unaligned access to all ELF data structures.
This patch in particular makes lld bug-compatible with icc. Intel C
compiler doesn't seem to care about data alignment and generates unaligned
relocation sections (https://bugs.llvm.org/show_bug.cgi?id=35854).
I also saw another instance of compatibility issues with our internal tool
which creates unaligned section headers.
Because GNU linkers are not picky about alignment, looks like it is
not uncommon that ELF-generating tools create unaligned files.
There is a performance penalty with this patch on host machines on which
unaligned access is expensive. x86 and AArch64 are fine. ARMv6 is a
problem, but I don't think using ARMv6 machines as hosts is common, so I
believe it's not a real problem.
Differential Revision: https://reviews.llvm.org/D41978
llvm-svn: 322407
|
|
|
|
|
|
|
|
|
|
| |
This adds some more detail about the PDB container format,
specifically surrounding the layout of the Free Page Map.
Patch by Colden Cullen
Differential Revision: https://reviews.llvm.org/D41825
llvm-svn: 322404
|
|
|
|
|
|
|
|
|
|
|
| |
a Constant
Summary:
In preparation for https://reviews.llvm.org/D41675 this NFC changes this
prototype of MemIntrinsicInst::setAlignment() to accept an unsigned instead
of a Constant.
llvm-svn: 322403
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision:
https://reviews.llvm.org/D38906
Reviewers:
Matt and Brian.
llvm-svn: 322402
|