| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One exception here is LoopInfo which must forward-declare it (because
the typedef is in LoopPassManager.h which depends on LoopInfo).
Also, some includes for LoopPassManager.h were needed since that file
provides the typedef.
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.
Thanks to David for the suggestion.
llvm-svn: 278079
|
|
|
|
|
|
|
|
|
|
|
| |
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.
Thanks to David for the suggestion.
llvm-svn: 278077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Shifts with a uniform but non-constant count were considered very expensive to
vectorize, because the splat of the uniform count and the shift would tend to
appear in different blocks. That made the splat invisible to ISel, and we'd
scalarize the shift at codegen time.
Since r201655, CodeGenPrepare sinks those splats to be next to their use, and we
are able to select the appropriate vector shifts. This updates the cost model to
to take this into account by making shifts by a uniform cheap again.
Differential Revision: https://reviews.llvm.org/D23049
llvm-svn: 277782
|
|
|
|
|
|
|
|
| |
The earlier change added hotness attribute to missed-optimization
remarks. This follows up with the analysis remarks (the ones explaining
the reason for the missed optimization).
llvm-svn: 276192
|
|
|
|
| |
llvm-svn: 275335
|
|
|
|
| |
llvm-svn: 275334
|
|
|
|
|
|
|
| |
In fact, don't even pass this to the ctor since we can get it from the
module.
llvm-svn: 275326
|
|
|
|
| |
llvm-svn: 275325
|
|
|
|
| |
llvm-svn: 275322
|
|
|
|
|
|
|
|
|
| |
Use range-base for loops.
Use auto when appropriate.
No functional change is intended.
llvm-svn: 275213
|
|
|
|
| |
llvm-svn: 274934
|
|
|
|
| |
llvm-svn: 274927
|
|
|
|
|
|
|
|
|
| |
We were inappropriately using 32-bit types to account for quantities
that can be far larger.
Fixed in PR28443.
llvm-svn: 274737
|
|
|
|
|
|
|
| |
Note that require<domtree> and require<loops> aren't needed because they
come in implicitly via the loop pass manager.
llvm-svn: 274712
|
|
|
|
|
|
|
| |
It is implemented as a LoopAnalysis pass as
discussed and agreed upon.
llvm-svn: 274452
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21636
llvm-svn: 274334
|
|
|
|
| |
llvm-svn: 274302
|
|
|
|
| |
llvm-svn: 274115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It did not handle correctly cases without GEP.
The following loop wasn't vectorized:
for (int i=0; i<len; i++)
*to++ = *from++;
I use getPtrStride() to find Stride for memory access and return 0 is the Stride is not 1 or -1.
Re-commit rL273257 - revision: http://reviews.llvm.org/D20789
llvm-svn: 273864
|
|
|
|
|
|
|
| |
To make definition of mov ctors easier.
Differential Revision: http://reviews.llvm.org/D21563
llvm-svn: 273506
|
|
|
|
| |
llvm-svn: 273258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It did not handle correctly cases without GEP.
The following loop wasn't vectorized:
for (int i=0; i<len; i++)
*to++ = *from++;
I use getPtrStride() to find Stride for memory access and return 0 is the Stride is not 1 or -1.
Differential revision: http://reviews.llvm.org/D20789
llvm-svn: 273257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a functional change for LLE and LDist. The other clients (LV,
LVerLICM) already had this explicitly enabled.
The temporary boolean parameter to LAA is removed that allowed turning
off speculation of symbolic strides. This makes LAA's caching interface
LAA::getInfo only take the loop as the parameter. This makes the
interface more friendly to the new Pass Manager.
The flag -enable-mem-access-versioning is moved from LV to a LAA which
now allows turning off speculation globally.
llvm-svn: 273064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is still NFCI, so the list of clients that allow symbolic stride
speculation does not change (yes: LV and LoopVersioningLICM, no: LLE,
LDist). However since the symbolic strides are now managed by LAA
rather than passed by client a new bool parameter is used to enable
symbolic stride speculation.
The existing test Transforms/LoopVectorize/version-mem-access.ll checks
that stride speculation is performed for LV.
The previously added test Transforms/LoopLoadElim/symbolic-stride.ll
ensures that no speculation is performed for LLE.
The next patch will change the functionality and turn on symbolic stride
speculation in all of LAA's clients and remove the bool parameter.
llvm-svn: 272970
|
|
|
|
|
|
| |
This is to facilitate to move of SymblicStrides from LV to LAA.
llvm-svn: 272879
|
|
|
|
|
|
|
| |
Soon we won't be passing Strides to getInfo and then we'll have fewer
call sites to update.
llvm-svn: 272878
|
|
|
|
| |
llvm-svn: 272243
|
|
|
|
|
|
|
|
| |
This is the preparation patch to port the analysis to new PM
Differential Revision: http://reviews.llvm.org/D20560
llvm-svn: 272194
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR26314. This patch adds new helper “isNoWrap” with detection of
loop-invariant pointer case.
Patch by Roman Shirokiy.
Ref: https://llvm.org/bugs/show_bug.cgi?id=26314
Differential Revision: http://reviews.llvm.org/D17268
llvm-svn: 272014
|
|
|
|
|
|
|
| |
Contributed-by: Aditya Kumar <hiraditya@msn.com>
Differential Revision: http://reviews.llvm.org/D20953
llvm-svn: 271895
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the order in which we attempt to prove the independence of
strided accesses. We previously did this after we knew the dependence distance
was positive. With this change, we check for independence before handling the
negative distance case. The patch prevents LAA from reporting forward
dependences for independent strided accesses.
This change was requested in the review of D19984.
llvm-svn: 270072
|
|
|
|
|
|
|
| |
This patch renames the option enabling the store-to-load forwarding conflict
detection optimization. This change was requested in the review of D20241.
llvm-svn: 269668
|
|
|
|
|
|
|
| |
Also s/Cycles/Iters/ in NumCyclesForStoreLoadThroughMemory to make it
clear that this is not about clock cycles but loop cycles/iterations.
llvm-svn: 269667
|
|
|
|
| |
llvm-svn: 269666
|
|
|
|
| |
llvm-svn: 269654
|
|
|
|
| |
llvm-svn: 269508
|
|
|
|
| |
llvm-svn: 269507
|
|
|
|
| |
llvm-svn: 269356
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Changing misleading function name was approved in http://reviews.llvm.org/D17268.
Patch by Roman Shirokiy.
llvm-svn: 269021
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functionality contained within getIntrinsicIDForCall is two-fold: it
checks if a CallInst's callee is a vectorizable intrinsic. If it isn't
an intrinsic, it attempts to map the call's target to a suitable
intrinsic.
Move the mapping functionality into getIntrinsicForCallSite and rename
getIntrinsicIDForCall to getVectorIntrinsicIDForCall while
reimplementing it in terms of getIntrinsicForCallSite.
llvm-svn: 266801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a print method to Predicated Scalar Evolution which prints all interesting
transformations done by PSE.
Loop Access Analysis will now print this as part of the analysis output.
We now use this to check the exact expression transformations that were done
by PSE in LAA.
The additional checking also acts as white-box testing for the getAsAddRec method.
Reviewers: anemet, sanjoy
Subscribers: sanjoy, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D18792
llvm-svn: 266334
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and LV
This re-commits r265535 which was reverted in r265541 because it
broke the windows bots. The problem was that we had a PointerIntPair
which took a pointer to a struct allocated with new. The problem
was that new doesn't provide sufficient alignment guarantees.
This pattern was already present before r265535 and it just happened
to work. To fix this, we now separate the PointerToIntPair from the
ExitNotTakenInfo struct into a pointer and a bool.
Original commit message:
Summary:
When the backedge taken codition is computed from an icmp, SCEV can
deduce the backedge taken count only if one of the sides of the icmp
is an AddRecExpr. However, due to sign/zero extensions, we sometimes
end up with something that is not an AddRecExpr.
However, we can use SCEV predicates to produce a 'guarded' expression.
This change adds a method to SCEV to get this expression, and the
SCEV predicate associated with it.
In HowManyGreaterThans and HowManyLessThans we will now add a SCEV
predicate associated with the guarded backedge taken count when the
analyzed SCEV expression is not an AddRecExpr. Note that we only do
this as an alternative to returning a 'CouldNotCompute'.
We use new feature in Loop Access Analysis and LoopVectorize to analyze
and transform more loops.
Reviewers: anemet, mzolotukhin, hfinkel, sanjoy
Subscribers: flyingforyou, mcrosier, atrick, mssimpso, sanjoy, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D17201
llvm-svn: 265786
|
|
|
|
| |
llvm-svn: 265541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When the backedge taken codition is computed from an icmp, SCEV can
deduce the backedge taken count only if one of the sides of the icmp
is an AddRecExpr. However, due to sign/zero extensions, we sometimes
end up with something that is not an AddRecExpr.
However, we can use SCEV predicates to produce a 'guarded' expression.
This change adds a method to SCEV to get this expression, and the
SCEV predicate associated with it.
In HowManyGreaterThans and HowManyLessThans we will now add a SCEV
predicate associated with the guarded backedge taken count when the
analyzed SCEV expression is not an AddRecExpr. Note that we only do
this as an alternative to returning a 'CouldNotCompute'.
We use new feature in Loop Access Analysis and LoopVectorize to analyze
and transform more loops.
Reviewers: anemet, mzolotukhin, hfinkel, sanjoy
Subscribers: flyingforyou, mcrosier, atrick, mssimpso, sanjoy, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D17201
llvm-svn: 265535
|
|
|
|
| |
llvm-svn: 264244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to only allow SCEVAddRecExpr for pointer expressions in order to
be able to compute the bounds. However this is also trivially possible
for loop-invariant addresses (scUnknown) since then the bounds are the
address itself.
Interestingly, we used allow this for the special case when the
loop-invariant address happens to also be an SCEVAddRecExpr (in an outer
loop).
There are a couple more loops that are vectorized in SPEC after this.
My guess is that the main reason we don't see more because for example a
loop-invariant load is vectorized into a splat vector with several
vector-inserts. This is likely to make the vectorization unprofitable.
I.e. we don't notice that a later LICM will move all of this out of the
loop so the cost estimate should really be 0.
llvm-svn: 264243
|