| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
SCEVExpander::replaceCongruentIVs assumes the backedge value of an
SCEV-analysable PHI to always be an instruction, when this is not
necessarily true. For now address this by bailing out of the
optimization if the backedge value of the PHI is a non-Instruction.
llvm-svn: 269213
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`SCEVExpander::replaceCongruentIVs` bypasses `hoistIVInc` if both the
original and the isomorphic increments are PHI nodes. Doing this can
break SSA if the isomorphic increment is not dominated by the original
increment. Get rid of the bypass, and let `hoistIVInc` do the right
thing.
Fixes PR27232 (compile time crash/hang).
llvm-svn: 269212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... for AddRec's in loops for which SCEV is unable to compute a max
tripcount. This is not a problem for "normal" loops[0] that don't have
guards or assumes, but helps in cases where we have guards or assumes in
the loop that can be used to constrain incoming values over the backedge.
This partially fixes PR27691 (we still don't handle the NUW case).
[0]: for "normal" loops, in the cases where we'd be able to prove
no-wrap via isKnownPredicate, we'd also be able to compute a max
tripcount.
llvm-svn: 269211
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Equivalent GEP indices with different types are treated as different
indices altogether, leading to an incorrect AA result. Fix the issue
by comparing indices based on their values.
Thanks to Mikael Holmén for reporting the issue!
Differential Revision: http://reviews.llvm.org/D19935
llvm-svn: 269197
|
| |
|
|
|
|
|
|
|
|
| |
Extract a part of isDereferenceableAndAlignedPointer functionality to Value:
Reviewed By: hfinkel, sanjoy
Differential Revision: http://reviews.llvm.org/D17611
llvm-svn: 269190
|
| |
|
|
| |
llvm-svn: 269138
|
| |
|
|
| |
llvm-svn: 269131
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do simplifications common to all shift instructions based on the amount shifted:
1. If the shift amount is known larger than the bitwidth, the result is undefined.
2. If the valid bits of the shift amount are all known to be 0, it's a shift by zero, so the shift operand is the result.
Note that we could generalize the shift-by-zero transform into a shift-by-constant if all of the valid bits in the shift
amount are known, but that would have to be done in InstCombine rather than here because it would mean we need to create
a new shift instruction.
Differential Revision: http://reviews.llvm.org/D19874
llvm-svn: 269114
|
| |
|
|
| |
llvm-svn: 269094
|
| |
|
|
|
|
| |
MSVC build.
llvm-svn: 269091
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Analysis.
The plan is to eventually make this logic simpler, however I expect it to
be a little tricky for the foreseeable future (at least until we're rid of
pointee types), so move it here so that it can be reused to build a summary
index for devirtualization.
Differential Revision: http://reviews.llvm.org/D20005
llvm-svn: 269081
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This removes a redundant stride versioning step (we already
do it in getPtrStride, so it has no effect) and uses PSE to
get the SCEV expressions for the source and destination
(this might have changed when getPtrStride was called).
I discovered this through code inspection, and couldn't
produce a regression test for it.
llvm-svn: 269052
|
| |
|
|
|
|
|
|
| |
This was a fairly simple patch but on closer inspection was seriously flawed and caused PR27690.
This reverts commit r268921.
llvm-svn: 269051
|
| |
|
|
|
|
|
| |
Changing misleading function name was approved in http://reviews.llvm.org/D17268.
Patch by Roman Shirokiy.
llvm-svn: 269021
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: apilipenko, majnemer, reames
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D20044
llvm-svn: 269008
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The idea is very close to what we do for assume intrinsics: we mark the
guard intrinsics as writing to arbitrary memory to maintain control
dependence, but under the covers we teach AA that they do not mod any
particular memory location.
Reviewers: chandlerc, hfinkel, gbiv, reames
Subscribers: george.burgess.iv, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19575
llvm-svn: 269007
|
| |
|
|
|
|
| |
The boolean expressions are somewhat hard to read otherwise.
llvm-svn: 268998
|
| |
|
|
|
|
|
|
|
| |
We can use calls to @llvm.experimental.guard to prove predicates,
relying on the fact that in all locations domianted by a call to
@llvm.experimental.guard the predicate it is guarding is known to be
true.
llvm-svn: 268997
|
| |
|
|
|
|
|
|
|
|
| |
When we encounter unsafe memory dependencies, loop distribution could
help.
Even though, the diagnostics is in LAA, it's only currently emitted in
the vectorizer.
llvm-svn: 268987
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20077
llvm-svn: 268980
|
| |
|
|
|
|
| |
The post dominator tree does not have a root node in this case.
llvm-svn: 268933
|
| |
|
|
| |
llvm-svn: 268929
|
| |
|
|
|
|
| |
When deciding if a vector calculation can be done in a smaller bitwidth, use sign bit information from ValueTracking to add more information and allow more truncations.
llvm-svn: 268921
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A number of libcalls don't exist in any particular lib but are, instead,
defined in math.h as inline functions (even in C mode!). Don't rely on
their existence when lowering @llvm.{cos,sin,floor,..}.f32, promote them
instead.
N.B. We had logic to handle FREM but were missing out on a number of
others. This change generalizes the FREM handling.
llvm-svn: 268875
|
| |
|
|
|
|
| |
There is no need to match the comparison instruction repeatedly.
llvm-svn: 268836
|
| |
|
|
| |
llvm-svn: 268835
|
| |
|
|
| |
llvm-svn: 268834
|
| |
|
|
|
|
|
|
|
|
|
| |
a helper function
This test was crashing, and currently it breaks bootstrapping clang with debuginfo
Differential Revision: http://reviews.llvm.org/D20008
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268715
|
| |
|
|
|
|
|
|
| |
This message used to be correct, when all we cared about was whether the
dependence was safe (i.e. NoDep) or unsafe. With the current more
precise characterization, this is a forward dep.
llvm-svn: 268695
|
| |
|
|
| |
llvm-svn: 268687
|
| |
|
|
|
|
|
| |
This should have NFC in the context of codegen, but may have positive
implications on compile-time.
llvm-svn: 268651
|
| |
|
|
| |
llvm-svn: 268636
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19839
llvm-svn: 268601
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantVector
We assumed that ConstantVectors would be rather uninteresting from the
perspective of analysis. However, this is not the case due to a quirk
of how LLVM handles vectors of i1. Vectors of i1 are not
ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's
SizeInBits differs from it's StoreSizeInBytes. This leads to it being
categorized as a ConstantVector instead of a ConstantDataVector.
Instead, treat ConstantVector more uniformly.
This fixes PR27591.
llvm-svn: 268479
|
| |
|
|
|
|
|
|
|
|
|
| |
A loop pass that didn't preserve this entire set of passes wouldn't
play well with other loop passes, since these are generally a basic
requirement to do any interesting transformations to a loop.
Adds a helper to get the set of analyses a loop pass should preserve,
and checks that any loop pass we run satisfies the requirement.
llvm-svn: 268444
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the "LoopDispositions:" section:
- Instead of printing out a list, print out a "dictionary" to make it
obvious by inspection which disposition is for which loop. This is
just a cosmetic change.
- Print dispositions for parent _and_ sibling loops. I will use this
to write a test case.
llvm-svn: 268405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary
When a non-escaping pointer is compared to a global value, the
comparison can be folded even if the corresponding malloc/allocation
call cannot be elided.
We need to make sure the global value is not null, since comparisons to
null cannot be folded.
In future, we should also handle cases when the the comparison
instruction dominates the pointer escape.
Reviewers: sanjoy
Subscribers s.egerton, llvm-commits
Differential Revision: http://reviews.llvm.org/D19549
llvm-svn: 268390
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We were overly cautious in our analysis of loops which have invokes
which unwind to EH pads. The loop unroll transform is safe because it
only clones blocks in the loop body, it does not try to split critical
edges involving EH pads. Instead, move the necessary safety check to
LoopUnswitch.
N.B. The safety check for loop unswitch is covered by an existing test
which fails without it.
llvm-svn: 268357
|
| |
|
|
|
|
|
|
|
| |
that it computes. Currently this is used for testing and precision
tuning, but it might be used by optimizations later.
Differential Revision: http://reviews.llvm.org/D19179
llvm-svn: 268291
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As shown in the diff, we used to add to CFLAA's cache by doing
`Cache[Fn] = buildSetsFrom(Fn)`. `buildSetsFrom(Fn)` may cause `Cache`
to reallocate its underlying storage, if this happens and `Cache[Fn]`
was evaluated prior to `buildSetsFrom(Fn)`, then we'll store the result
to a bad address.
Patch by Jia Chen.
llvm-svn: 268269
|
| |
|
|
| |
llvm-svn: 268198
|
| |
|
|
|
|
|
|
|
|
|
| |
There are currently some bugs in tree around SCEV caching an incorrect
loop disposition. Printing out loop dispositions will let us write
whitebox tests as those are fixed.
The dispositions are printed as a list in "inside out" order,
i.e. innermost loop first.
llvm-svn: 268177
|
| |
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 268108
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19550
llvm-svn: 268104
|
| |
|
|
|
|
|
|
|
|
|
|
| |
matchSelectPattern attempts to see through casts which mask min/max
patterns from being more obvious. Under certain circumstances, it would
misidentify a sequence of instructions as a min/max because it assumed
that folding casts would preserve the result. This is not the case for
floating point <-> integer casts.
This fixes PR27575.
llvm-svn: 268086
|
| |
|
|
|
|
|
|
|
|
|
|
| |
getModRefBehavior(Function)
Reviewers: dberlin, chandlerc, hfinkel, reames, sanjoy
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19730
llvm-svn: 268068
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cmake build to enable them.
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
llvm-svn: 268050
|
| |
|
|
|
|
|
| |
Unreachable blocks may not be in the dominator tree,
so don't crash on them.
llvm-svn: 268001
|
| |
|
|
|
|
|
| |
Patch by Aditya Kumar!
Differential Revision: http://reviews.llvm.org/D19047
llvm-svn: 267888
|
| |
|
|
|
|
|
|
|
| |
I tried to be as close as possible to the strongest check that
existed before; cleaning these up properly is left for future work.
Differential Revision: http://reviews.llvm.org/D19469
llvm-svn: 267758
|