[PATCH] D14240: Allow Loop Distribute and the loop versioning infrastructure to use SCEV predicates
silviu.baranga@arm.com via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 6 05:15:49 PST 2015
sbaranga added a comment.
In http://reviews.llvm.org/D14240#283209, @anemet wrote:
> In http://reviews.llvm.org/D14240#282137, @sbaranga wrote:
>
> > However if we wouldn't be interested in the answer for canVectorizeMemory() it should be possible to change MemoryDepChecker::areDepsSafe in LAA such that we have a per-dependence predicate. Then we can ignore the predicates dependences we don't care about. Do you think this approach makes sense?
>
>
> I am not saying we should implement this but I'd like to think about this now before committing to a design where we'd have no way of dropping unnecessary predicates.
>
> I am not sure that we need per-dependence predicates though. I think it needs to be per alias set. If you have a pointer that may wrap that can now have a dependence to any of the pointers in the same alias set. It is still OK to drop this predicate for loop distribution if all members of this alias set fall into the same partition.
>
> Where are we going to use SCEVPreds with alias checks? Is it to try to shape a SCEV into an AddRec?
Yes, we would use these to get AddRec expressions. I've also found one additional use case where it's already an AddRec and we want to check for nuw or nsw (see isStridedPtr).
================
Comment at: include/llvm/Transforms/Utils/LoopVersioning.h:74-76
@@ -74,1 +73,5 @@
+ /// \brief Adds a set of runtime alias checks for versioning the loop.
+ void addAliasChecks(
+ const SmallVectorImpl<RuntimePointerChecking::PointerCheck> &Checks);
+
----------------
anemet wrote:
> Sorry I didn't realize that by suggesting "add" in the name you would make this "additive". The problem is now we lost the nice "move constructibility" of Checks.
>
> How about making this setAliasChecks which would still take a value and then restoring the std::move's.
>
> Would a set* interface work for SCEVUnionPredicate?
Ok, I understand. It wouldn't work at the moment for SCEVUnionPredicate. We need to define copy and move constructors for it. I'll create another review for that.
http://reviews.llvm.org/D14240
More information about the llvm-commits
mailing list