search for: scevfaddexpr

...`sitofp` and `uitofp` over? Same questions for `fptosi` and `fptoui`. - How will you partition the logic between floating and integer expressions in SCEV-land? Will you have, say, `SCEVAddExpr` do different things based on type, or will you split it into `SCEVIAddExpr` and `SCEVFAddExpr`? [0] * There are likely to be similarities too -- e.g. the "inductive" or "control flow" aspect of `SCEVAddRecExpr` is likely to be common between floating point add recurrences[1], and integer add recurrences; and part of figuring out the partitioning is...

...onsidered as IV in this loop. > > And this loop is not vectorized because “f” is floating point. > > I don’t think that the case **B** is uncommon. If B is the case we actually care about, I'd say changing SCEV to work with floating points is an overkill. How would you expect an SCEVFAddExpr to help vectorize B, other than tell you what the initial value and the increment is (and these can be found with a simple value analysis)? If we're interested in handling complex variants of A directly: computing trip counts, proving away predicates etc. without translating the loops to u...

...riable “f” is also considered as IV in this loop. And this loop is not vectorized because “f” is floating point. I don’t think that the case **B** is uncommon. If B is the case we actually care about, I'd say changing SCEV to work with floating points is an overkill. How would you expect an SCEVFAddExpr to help vectorize B, other than tell you what the initial value and the increment is (and these can be found with a simple value analysis)? One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I...

...na] the same answer as above, because I don’t want to combine these operations - How will you partition the logic between floating and integer expressions in SCEV-land? Will you have, say, `SCEVAddExpr` do different things based on type, or will you split it into `SCEVIAddExpr` and `SCEVFAddExpr`? [0] [Demikhovsky, Elena] Yes, I’m introducing SCEVFAddExpr and SCEVFMulExpr - (start + delta * sitofp(i)) * There are likely to be similarities too -- e.g. the "inductive" or "control flow" aspect of `SCEVAddRecExpr` is likely to be common between floating po...

...riable “f” is also considered as IV in this loop. And this loop is not vectorized because “f” is floating point. I don’t think that the case **B** is uncommon. If B is the case we actually care about, I'd say changing SCEV to work with floating points is an overkill. How would you expect an SCEVFAddExpr to help vectorize B, other than tell you what the initial value and the increment is (and these can be found with a simple value analysis)? One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I...

...as IV in this loop. > > And this loop is not vectorized because “f” is floating point. > > I don’t think that the case **B** is uncommon. > > If B is the case we actually care about, I'd say changing SCEV to work with floating points is an overkill. How would you expect an SCEVFAddExpr to help vectorize B, other than tell you what the initial value and the increment is (and these can be found with a simple value analysis)? > > One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy sug...

...n this loop. > > And this loop is not vectorized because “f” is floating point. > > I don’t think that the case **B** is uncommon. > > > If B is the case we actually care about, I'd say changing SCEV to work with > floating points is an overkill. How would you expect an SCEVFAddExpr to > help vectorize B, other than tell you what the initial value and the > increment is (and these can be found with a simple value analysis)? > > > One option would be to extend InductionDescriptor::isInductionPHI in the > vectorizer to directly analyze the PHIs without SCEV sup...

Hi, I'm working now on extending SCEV Analysis and adding FP support. At the beginning, I want to vectorize this loop: float fp_inc; float x = init; for (int i=0;i<N;i++){ A[i] = x; x += fp_inc; // Loop invariant variable or constant } In this loop "x" is a FP induction variable. But it is not the "primary" induction and loop trip count is still depends

On Tue, May 17, 2016 at 8:49 PM Owen Anderson <resistor at mac.com> wrote: > > On May 16, 2016, at 2:42 PM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > - Core motivation: why do we even care about optimizing floating > point induction variables? What situations are they common in? Do > programmers _expect_ compilers to optimize them