search for: recurrencedescriptor

...oving LoopVectorizationLegality out of LoopVectorize.cpp in order to make it reusable. For example, other transformations can change the behavior depending on whether the loop is vectorizable or not. Ideally, such analysis type code belongs to Analysis tree. One of the blocking factor is its use of RecurrenceDescriptor/InductionDescriptor, defined in Transform/Utils/LoopUtils.h. Anything I should know before attempting to move those Descriptors under Analysis/Utils? Like known dependencies making them very hard to move to Analysis tree? Recurrence and Inductions are again analysis type stuff. They really belong...

...%sub = add i32 %add, %conv7 %j.1 = add nuw nsw i16 %j.03, 1 %h.1 = load i32, i32* %hp.1, align 1, !tbaa !4 %cmp3 = icmp ult i16 %j.03, 99 br i1 %cmp3, label %inner.body, label %inner.end, !llvm.loop !8 And the vectorizer bails out since the load is placed "late" in the loop, so RecurrenceDescriptor::isFirstOrderRecurrence returns false. If we just move the load before the definition of %0 in the vectorizer input, then we instead get LV: We can vectorize this loop! Originally the loop had two loads, and then one of them was actually placed early in the loop block. That was done by instcombi...

Thanks, Hal and Matt for the feedback. As usual, my instincts about canonicalization were probably wrong. :) I thought that @max1 vs. @max3 would be viewed as an unknowable trade-off between reducing the dependency chain and the pseudo-canonical min/max form, so we'd add intrinsics, and defer that decision to the backend. I'll wait to see if there are any other arguments presented.

...ed to check if the PHI is an add-recurrence that was detected by SCEV. The idea is to add a fall-back to analyze the PHI directly if its type is a float. There is already precedence for such things in LV. We support more reductions (including floating-point) than what SCEV can analyze, therefore RecurrenceDescriptor::AddReductionVar needs to analyze PHIs directly. Adam > > Thanks, > Hideki > > ---------------------- > I looked at what our FORTRAN compiler (non-LLVM) does for the following (x, y, z, and f are float by default typing, > based on names). > > subroutine fo...

...> add-recurrence that was detected by SCEV. The idea is to add a fall-back to > analyze the PHI directly if its type is a float. > > There is already precedence for such things in LV. We support more > reductions (including floating-point) than what SCEV can analyze, therefore > RecurrenceDescriptor::AddReductionVar needs to analyze PHIs directly. > > Adam > > > Thanks, > Hideki > > ---------------------- > I looked at what our FORTRAN compiler (non-LLVM) does for the following (x, > y, z, and f are float by default typing, > based on names). > > s...

What LoopVectorize.cpp has are the following. Each function may have to have a separate consolidation discussion. I'm bringing up getpointerOperand() since I actually found multiple instances defined/used. DependenceAnalysis.cpp has isLoadOrStore(). LoopAccessAnalysis.cpp has getAddressSpaceOperand(). I'm sure there are others that might be worth discussing within this thread or a follow

To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, people aren’t opposed to that. For me, handling case A (primary induction) is “why not?”, but I certainly admit that that can be very naïve thinking coming from lack of good understanding on SCEV and their proper usages. Now, let’s assume we can postpone discussion about case A. What is the

...loops the scalar calls must only occur for active lanes so we introduce predicated versions of the most common routines (e.g. `*llvm.pow`). This is mostly transparent to the loop vectorizer beyond the requirement to pass an extra parameter. ### TTI Interface: ```cpp bool canReduceInVector(const RecurrenceDescriptor &Desc, bool NoNaN) const; Value* getReductionIntrinsic(IRBuilder<> &Builder, const RecurrenceDescriptor& Desc, bool NoNaN, Value* Src) const; ``` # SelectionDAG Nodes ## *ISD::BUILD_VECTOR* {#isdbuildvector} `BUILD...

...has a reduction descriptor (obtained from a LoopUtils analysis of the loop's PHIs). If we want to generate from a descriptor: Value *llvm::createTargetReduction(IRBuilder<> &Builder, const TargetTransformInfo *TTI, RecurrenceDescriptor &Desc, Value *Src, bool InOrder, bool NoNaN) Or if no descriptor is given, then an alternative API call: Value *llvm::createTargetReduction(IRBuilder<> &Builder, const TargetTransformInfo *TTI,...