| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 290848
|
| |
|
|
| |
llvm-svn: 290844
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Regardless how the loop body weight is distributed, we should preserve
total loop body weight. i.e. we should have same weight reaching the body of the loop
or its duplicates in peeled and unpeeled case.
Reviewers: mkuper, davidxl, anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28179
llvm-svn: 290833
|
| |
|
|
| |
llvm-svn: 290828
|
| |
|
|
| |
llvm-svn: 290827
|
| |
|
|
|
|
|
| |
The checks were improved with:
https://reviews.llvm.org/rL290194
llvm-svn: 290826
|
| |
|
|
|
|
|
| |
It placates some bots which complain because they compile the
assertion out and think the variable is unused.
llvm-svn: 290825
|
| |
|
|
|
|
|
|
|
| |
Apparently my suggestion of using ternary doesn't really work
as clang complains about incompatible types on LHS and RHS. Some
GCC versions happen to accept the code but clang behaviour is
correct here.
llvm-svn: 290822
|
| |
|
|
| |
llvm-svn: 290820
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an explicit LLVM_ENABLE_DIA_SDK option to control building support
for DIA SDK-based debugging. Control its value to match whether DIA SDK
support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB).
Its value is needed for LLDB to determine whether to run tests requiring
DIA support. Currently it is obtained from llvm/Config/config.h;
however, this file is not available for standalone builds. Following
this change, LLDB will be modified to use the value from LLVMConfig.
Differential Revision: https://reviews.llvm.org/D26255
llvm-svn: 290818
|
| |
|
|
|
|
|
|
|
|
|
| |
GNU as rejects input where .cfi_sections is used after .cfi_startproc,
if the new section differs from the old. Adjust our output to always
emit .cfi_sections before the first .cfi_startproc to minimize necessary
code.
Differential Revision: https://reviews.llvm.org/D28011
llvm-svn: 290817
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kill fragile machinery for handling null expressions.
Summary:
This avoids the very fragile code for null expressions. We could also use a denseset that tracks which things have null expressions instead, but that seems pretty fragile and premature optimization.
This resolves a number of infinite loop cases, test reductions coming.
Reviewers: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28193
llvm-svn: 290816
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
handling works.
Summary: Previously, we tried to fix up the equivalences during symbolic evaluation. This does not work. Now, we change the equivalences during congruence finding, where it belongs. We also initialize the equivalence table to give a maximal answer.
Reviewers: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28192
llvm-svn: 290815
|
| |
|
|
|
|
| |
The pass has been on by default for a long time without problems.
llvm-svn: 290814
|
| |
|
|
|
|
| |
(This changed was approved in https://reviews.llvm.org/D28118, but Simon asked to submit it separately).
llvm-svn: 290812
|
| |
|
|
|
|
|
|
|
|
|
|
| |
X86 target does not provide any target specific cost calculation for interleave patterns.It uses the common target-independent calculation, which gives very high numbers. As a result, the scalar version is chosen in many cases. The situation on AVX-512 is even worse, since we have 3-src shuffles that significantly reduce the cost.
In this patch I calculate the cost on AVX-512. It will allow to compare interleave pattern with gather/scatter and choose a better solution (PR31426).
* Shiffle-broadcast cost will be changed in Simon's upcoming patch.
Differential Revision: https://reviews.llvm.org/D28118
llvm-svn: 290810
|
| |
|
|
|
|
|
| |
This reapplies rL289013 (reverted in rL289014) with the fixes identified
in D21731. Should hopefully pass the buildbots this time.
llvm-svn: 290809
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`PromotedFloats` needs to be checked in
`DAGTypeLegalizer::PerformExpensiveChecks`. This patch fixes a few type
legalization failures with expansive checks for ARM fp16 tests.
Reviewers: baldrick, bogner, arsenm
Subscribers: arsenm, aemerson, llvm-commits
Differential Revision: https://reviews.llvm.org/D28187
llvm-svn: 290796
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure if this was intentional, but today
isGuaranteedToTransferExecutionToSuccessor returns true for readonly and
argmemonly calls that may throw. This commit changes the function to
not implicitly infer nounwind this way.
Even if we eventually specify readonly calls as not throwing,
isGuaranteedToTransferExecutionToSuccessor is not the best place to
infer that. We should instead teach FunctionAttrs or some other such
pass to tag readonly functions / calls as nounwind instead.
llvm-svn: 290794
|
| |
|
|
| |
llvm-svn: 290793
|
| |
|
|
|
|
|
| |
We bail out on the 1st line if the assumption cache is not set, so there's
no need to check it after that.
llvm-svn: 290787
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isKnownNonNullFromDominatingCondition(); NFCI
I don't think this hole is currently exposed, but I crashed regression tests for
jump-threading and loop-vectorize after I added calls to isKnownNonNullAt() in
InstSimplify as part of trying to solve PR28430:
https://llvm.org/bugs/show_bug.cgi?id=28430
That's because they call into value tracking with a context instruction, but no
other parts of the query structure filled in.
For more background, see the discussion in:
https://reviews.llvm.org/D27855
llvm-svn: 290786
|
| |
|
|
|
|
|
|
| |
This was originally motivated by a compile time problem I've since figured out how to solve differently, but the cleanup seemed useful. We had the same logic - which essentially implemented find - in several places. By commoning them out, I can implement find and allow erase to be inlined at the call sites if profitable.
Differential Revision: https://reviews.llvm.org/D28183
llvm-svn: 290779
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR 31345
Reviewers: dylanmckay
Subscribers: fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D28186
llvm-svn: 290778
|
| |
|
|
|
|
|
|
| |
llvm.x86.avx512.vcomi.ss don't use the upper elements of their input.
This was already done for the SSE/SSE2 version of the intrinsics.
llvm-svn: 290776
|
| |
|
|
|
|
|
|
| |
don't emit a select if the mask is known to be all ones.
This saves InstCombine the burden of having to optimize the select later.
llvm-svn: 290774
|
| |
|
|
| |
llvm-svn: 290769
|
| |
|
|
|
|
| |
Minor compile time win. Avoids an additional O(N) scan in the case where we are removing an element and costs nothing when we aren't.
llvm-svn: 290768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
gep 0, 0 is equivalent to bitcast. LLVM canonicalizes it
to getelementptr because it make SROA can then handle it.
Simple case like
void g(A &a) {
z(a);
if (glob)
a.foo();
}
void testG() {
A a;
g(a);
}
was not devirtualized with -fstrict-vtable-pointers because luck of
handling for gep 0 in Memory Dependence Analysis
Reviewers: dberlin, nlewycky, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28126
llvm-svn: 290763
|
| |
|
|
|
|
|
|
| |
CVP doesn't care about the order of blocks visited, but by using a pre-order traversal over the graph we can a) not visit unreachable blocks and b) optimize as we go so that analysis of later blocks produce slightly more precise results.
I noticed this via inspection and don't have a concrete example which points to the issue.
llvm-svn: 290760
|
| |
|
|
|
|
| |
Minor compile time win. Not known to be a hot spot, just something I noticed while reading.
llvm-svn: 290759
|
| |
|
|
|
|
| |
an unlikely thing to regress in the future.
llvm-svn: 290757
|
| |
|
|
| |
llvm-svn: 290755
|
| |
|
|
| |
llvm-svn: 290741
|
| |
|
|
| |
llvm-svn: 290739
|
| |
|
|
|
|
|
|
|
| |
This is similar to the allocfn case - if an alloca is not captured, then it's
necessarily thread-local.
Differential Revision: https://reviews.llvm.org/D28170
llvm-svn: 290738
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current loop complete unroll algorithm checks if unrolling complete will reduce the runtime by a certain percentage. If yes, it will apply a fixed boosting factor to the threshold (by discounting cost). The problem for this approach is that the threshold abruptly. This patch makes the boosting factor a function of runtime reduction percentage, capped by a fixed threshold. In this way, the threshold changes continuously.
The patch also simplified the code by reducing one parameter in UP.
The patch only affects code-gen of two speccpu2006 benchmark:
445.gobmk binary size decreases 0.08%, no performance change.
464.h264ref binary size increases 0.24%, no performance change.
Reviewers: mzolotukhin, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26989
llvm-svn: 290737
|
| |
|
|
|
|
|
|
| |
"Changed" doesn't actually change within the loop, so there's
no reason to keep track of it - we always return false during
analysis and true after the transformation is made.
llvm-svn: 290735
|
| |
|
|
| |
llvm-svn: 290734
|
| |
|
|
|
|
|
|
| |
We correctly canonicalized (add (sext x), (sext y)) to (sext (add x, y))
where possible. However, we didn't perform the same canonicalization
for zexts or for muls.
llvm-svn: 290733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR 31344
Authored by Anmol P. Paralkar
Reviewers: dylanmckay
Subscribers: fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D28121
llvm-svn: 290732
|
| |
|
|
|
|
|
| |
I'm preparing to add some pattern matching code here, so simplify the
code before I do. NFC
llvm-svn: 290731
|
| |
|
|
| |
llvm-svn: 290730
|
| |
|
|
|
|
|
|
|
|
|
| |
This moves the exit block and insertion point computation to be eager,
instead of after seeing the first scalar we can promote.
The cost is relatively small (the computation happens anyway, see discussion
on D28147), and the code is easier to follow, and can bail out earlier
if there's a catchswitch present.
llvm-svn: 290729
|
| |
|
|
|
|
|
|
|
|
| |
We would check whether we have a prehader *or* dedicated exit blocks,
and go into the promotion loop. Then, for each alias set we'd check
if we have a preheader *and* dedicated exit blocks, and bail if not.
Instead, bail immediately if we don't have both.
llvm-svn: 290728
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We want to recompute LCSSA only when we actually promoted a value.
This means we only need to look at changes made by promotion when
deciding whether to recompute it or not, not at regular sinking/hoisting.
(This was what the code was documented as doing, just not what it did)
Hopefully NFC.
llvm-svn: 290726
|
| |
|
|
|
|
| |
Change to one based numbering so we can assert we don't cause the same bug again.
llvm-svn: 290724
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This class is unnecessary.
Its comment indicated that it was a compile error to allocate an
instance of a class that inherits from RefCountedBaseVPTR on the stack.
This may have been true at one point, but it's not today.
Moreover you really do not want to allocate *any* refcounted object on
the stack, vptrs or not, so if we did have a way to prevent these
objects from being stack-allocated, we'd want to apply it to regular
RefCountedBase too, obviating the need for a separate RefCountedBaseVPTR
class.
It seems that the main way RefCountedBaseVPTR provides safety is by
making its subclass's destructor virtual. This may have been helpful at
one point, but these days clang will emit an error if you define a class
with virtual functions that inherits from RefCountedBase but doesn't
have a virtual destructor.
Reviewers: compnerd, dblaikie
Subscribers: cfe-commits, klimek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28162
llvm-svn: 290717
|
| |
|
|
|
|
|
|
| |
This reverts commit r290694. It broke sanitizer tests on Win64. I'll
probably bring this back, but the jump tables will just live in .text
like they do for MSVC.
llvm-svn: 290714
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes the issue exposed in PR31393, where we weren't trying
sufficiently hard to diagnose bad TBAA metadata.
This does reduce the variety in the error messages we print out, but I
think the tradeoff of verifying more, simply and quickly overrules the
need for more helpful error messags here.
llvm-svn: 290713
|