| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 373849
|
|
|
|
| |
llvm-svn: 373848
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR43501)
https://bugs.llvm.org/show_bug.cgi?id=43501
We can't declare a GEP 'inbounds' in general. But we may salvage that information if
we have known dereferenceable bytes on the source pointer.
Differential Revision: https://reviews.llvm.org/D68244
llvm-svn: 373847
|
|
|
|
|
|
|
|
|
|
| |
We can make use of the Zeroable mask to indicate which elements we can safely set to zero instead of creating a target shuffle mask on the fly.
This allows us to remove createTargetShuffleMask.
This is part of the work to fix PR43024 and allow us to use SimplifyDemandedElts to simplify shuffle chains - we need to get to a point where the target shuffle masks isn't adjusted by its source inputs in setTargetShuffleZeroElements but instead we cache them in a parallel Zeroable mask.
llvm-svn: 373846
|
|
|
|
| |
llvm-svn: 373845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The Google C++ and Chromium style guides are broken in the clang-format docs. This patch updates them.
Reviewers: djasper, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang
Patch by: m4tx
Differential Revision: https://reviews.llvm.org/D61256
llvm-svn: 373844
|
|
|
|
| |
llvm-svn: 373842
|
|
|
|
| |
llvm-svn: 373841
|
|
|
|
| |
llvm-svn: 373840
|
|
|
|
| |
llvm-svn: 373839
|
|
|
|
|
|
| |
Turn into shift and truncate. Doesn't yet handle pointers.
llvm-svn: 373838
|
|
|
|
|
|
| |
This wasn't updated for the immarg handling change.
llvm-svn: 373837
|
|
|
|
|
|
| |
Fixes PR43575.
llvm-svn: 373836
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR42025)
As discussed on PR42025, with more complex boolean math we can end up with many truncations/extensions of the comparison results through each bitop.
This patch handles the cases introduced in combineBitcastvxi1 by pushing the sign extension through the AND/OR/XOR ops so its just the original SETCC ops that gets extended.
Differential Revision: https://reviews.llvm.org/D68226
llvm-svn: 373834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't see an ideal solution to these 2 related, potentially large, perf regressions:
https://bugs.llvm.org/show_bug.cgi?id=42708
https://bugs.llvm.org/show_bug.cgi?id=43146
We decided that load combining was unsuitable for IR because it could obscure other
optimizations in IR. So we removed the LoadCombiner pass and deferred to the backend.
Therefore, preventing SLP from destroying load combine opportunities requires that it
recognizes patterns that could be combined later, but not do the optimization itself (
it's not a vector combine anyway, so it's probably out-of-scope for SLP).
Here, we add a scalar cost model adjustment with a conservative pattern match and cost
summation for a multi-instruction sequence that can probably be reduced later.
This should prevent SLP from creating a vector reduction unless that sequence is
extremely cheap.
In the x86 tests shown (and discussed in more detail in the bug reports), SDAG combining
will produce a single instruction on these tests like:
movbe rax, qword ptr [rdi]
or:
mov rax, qword ptr [rdi]
Not some (half) vector monstrosity as we currently do using SLP:
vpmovzxbq ymm0, dword ptr [rdi + 1] # ymm0 = mem[0],zero,zero,..
vpsllvq ymm0, ymm0, ymmword ptr [rip + .LCPI0_0]
movzx eax, byte ptr [rdi]
movzx ecx, byte ptr [rdi + 5]
shl rcx, 40
movzx edx, byte ptr [rdi + 6]
shl rdx, 48
or rdx, rcx
movzx ecx, byte ptr [rdi + 7]
shl rcx, 56
or rcx, rdx
or rcx, rax
vextracti128 xmm1, ymm0, 1
vpor xmm0, xmm0, xmm1
vpshufd xmm1, xmm0, 78 # xmm1 = xmm0[2,3,0,1]
vpor xmm0, xmm0, xmm1
vmovq rax, xmm0
or rax, rcx
vzeroupper
ret
Differential Revision: https://reviews.llvm.org/D67841
llvm-svn: 373833
|
|
|
|
|
|
| |
Rename some variables to match lowerShuffleAsRepeatedMaskAndLanePermute - prep work toward adding some equivalent sublane functionality.
llvm-svn: 373832
|
|
|
|
| |
llvm-svn: 373831
|
|
|
|
|
|
|
|
|
|
| |
Added some tests testing urem and srem operations with a constant divisor.
Patch by TG908 (Tim Gymnich)
Differential Revision: https://reviews.llvm.org/D68421
llvm-svn: 373830
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373829
|
|
|
|
|
|
| |
Warning message looks better; and GCC adds it too.
llvm-svn: 373828
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373827
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373826
|
|
|
|
|
|
| |
Fixes cppcheck warning.
llvm-svn: 373825
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373824
|
|
|
|
|
|
| |
Silences static analyzer null dereference warnings.
llvm-svn: 373823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters.
Looking through the revision history, it appears support for only array brackets was added, and lambda brackets were ignored. Therefore, I am inclined to think it was simply an omission, rather than a deliberate choice.
See https://bugs.llvm.org/show_bug.cgi?id=17887 and https://reviews.llvm.org/D4944.
Reviewers: MyDeveloperDay, reuk, owenpan
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Patch by: mitchell-stellar
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68473
llvm-svn: 373821
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This looks like a defect in gcc-5 where it chooses a constexpr
constructor from the initializer-list that it considers to be explicit.
I've tried to reproduce but I can't install anything prior to gcc-6 easily
on my system, and that doesn't have the error. So this is speculative
pacification.
Reported by Steven Wan.
llvm-svn: 373820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AFAIK, lit-cpuid is used by the tests.
Installing it causes LLVMExports*.cmake files to depend
on this program.
It causes some serious packaging issues as it would means
that llvm-dev depends on lldb.
See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941082
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941306
See also https://bugs.llvm.org/show_bug.cgi?id=43035
for a similar issue caused by
https://reviews.llvm.org/D56606
Reviewers: mgorny
Reviewed By: mgorny
Subscribers: delcypher, lldb-commits
Differential Revision: https://reviews.llvm.org/D68537
llvm-svn: 373819
|
|
|
|
| |
llvm-svn: 373818
|
|
|
|
|
|
|
|
| |
negation of bool in languages without a bool type
Thanks for this advice, Richard Trieu!
llvm-svn: 373817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivation is to reuse the key value parsing logic here to
parse instance specific pass options within the context of MLIR.
The primary functionality exposed is the "," splitting for
arrays and the logic for properly handling duplicate definitions
of a single flag.
Patch by: Parker Schuh <parkers@google.com>
Differential Revision: https://reviews.llvm.org/D68294
llvm-svn: 373815
|
|
|
|
|
|
|
|
|
|
| |
This is an omission in rL371441. Loads which happened to be unordered weren't being added to the PendingLoad set, and thus weren't be ordered w/respect to side effects which followed before the end of the block.
Included test case is how I spotted this. We had an atomic load being folded into a using instruction after a fence that load was supposed to be ordered with. I'm sure it showed up a bunch of other ways as well.
Spotted via manual inspecting of assembly differences in a corpus w/and w/o the new experimental mode. Finding this with testing would have been "unpleasant".
llvm-svn: 373814
|
|
|
|
| |
llvm-svn: 373813
|
|
|
|
|
|
| |
simm9_lsb0 and simm12_lsb0 operand types were missing predicates.
llvm-svn: 373812
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: vsk, tejohnson
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D68095
llvm-svn: 373811
|
|
|
|
| |
llvm-svn: 373810
|
|
|
|
|
|
|
|
|
|
| |
LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY
If you explicitly set LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY to OFF, your
project will fail to configure because the cxx_experimental target
doesn't exist.
llvm-svn: 373809
|
|
|
|
|
|
|
|
| |
Also, set those flags for the cxx_experimental target. Otherwise,
cxx_experimental doesn't build properly when neither the static nor
the shared library is compiled (yes, that is a weird setup).
llvm-svn: 373808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subscribers: llvm-commits
Tags: #llvm
Reviewers: compnerd, vsk, sebpop, fhahn, tejohnson
Reviewed by: vsk
Differential Revision: https://reviews.llvm.org/D68478
llvm-svn: 373807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[libomptarget][nfc] Update remaining uint32 to use lanemask_t
Update a few functions in the API to use lanemask_t instead of i32. NFC for
nvptx. Also update the ActiveThreads type in DataSharingStateTy.
This removes a lot of #ifdef from the downsteam amdgcn implementation.
Reviewers: ABataev, jdoerfert, grokos, ronlieb, RaviNarayanaswamy
Subscribers: openmp-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D68513
llvm-svn: 373806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimize the blocks
This reverts r371177 (git commit f879c6875563c0a8cd838f1e13b14dd33558f1f8)
It caused PR43566 by removing empty, address-taken MachineBasicBlocks.
Such blocks may have references from blockaddress or other operands, and
need more consideration to be removed.
See the PR for a test case to use when relanding.
llvm-svn: 373805
|
|
|
|
|
|
|
| |
Now that we do shell expansion on POSIX with the user's shel, this test
can potentially fail. This should ensure that we always use /bin/sh.
llvm-svn: 373804
|
|
|
|
| |
llvm-svn: 373803
|
|
|
|
|
|
|
|
|
|
|
| |
'icmp sge/slt %x, 0'
We do indeed already get it right in some cases, but only transitively,
with one-use restrictions. Since we only need to produce a single
comparison, it makes sense to match the pattern directly:
https://rise4fun.com/Alive/kPg
llvm-svn: 373802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR43564, PR42391)
Initially (D65380) i believed that if we have rightshift-trunc-rightshift,
we can't do any folding. But as it usually happens, i was wrong.
https://rise4fun.com/Alive/GEw
https://rise4fun.com/Alive/gN2O
In https://bugs.llvm.org/show_bug.cgi?id=43564 we happen to have
this very sequence, of two right shifts separated by trunc.
And "just" so that happens, we apparently can fold the pattern
if the total shift amount is either 0, or it's equal to the bitwidth
of the innermost widest shift - i.e. if we are left with only the
original sign bit. Which is exactly what is wanted there.
llvm-svn: 373801
|
|
|
|
| |
llvm-svn: 373800
|
|
|
|
| |
llvm-svn: 373799
|
|
|
|
|
|
|
|
| |
trunc) (PR43564)
https://rise4fun.com/Alive/x5IS
llvm-svn: 373798
|
|
|
|
|
|
|
|
| |
trunc) (PR43564, PR42391)
https://rise4fun.com/Alive/GEw
llvm-svn: 373797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current version of the pretty printers are not python3 compatible,
so turn them off by default until sufficiently improved.
Reviewers: MaskRay, tamur
Subscribers: mgorny, christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68477
llvm-svn: 373796
|