[llvm-dev] Working on FP SCEV Analysis

Thu May 19 19:03:22 PDT 2016

On Thu, May 19, 2016 at 7:03 AM Demikhovsky, Elena <
elena.demikhovsky at intel.com> wrote:

> > One option would be to extend InductionDescriptor::isInductionPHI in the
> vectorizer to directly analyze the PHIs without SCEV support as Sanjoy
> suggested.  I *think* that that could be sufficient to handle case B.
>
>
>
> I implemented this with FP SCEV and the code looks very structured,
> including SCEVExpander. Extending the existing structures without
> implementing FP SCEV will be problematic.
>
> And my end goal is to handle case **A**.
>
Ok, but there have been *numerous* requests for an explanation of why this
is important, and that hasn't emerged yet.

We really need to have a clear understanding of the relative importance of
solving these problems in order to understand the best approach.

>
>
>
>
> -          * Elena*
>
>
>
> *From:* anemet at apple.com [mailto:anemet at apple.com]
> *Sent:* Thursday, May 19, 2016 07:43
> *To:* Sanjoy Das <sanjoy at playingwithpointers.com>
> *Cc:* Demikhovsky, Elena <elena.demikhovsky at intel.com>; Saito, Hideki <
> hideki.saito at intel.com>; llvm-dev <llvm-dev at lists.llvm.org>; Andrew Trick
> <atrick at apple.com>
>
>
> *Subject:* Re: [llvm-dev] Working on FP SCEV Analysis
>
>
>
>
>
> On May 18, 2016, at 12:17 PM, Sanjoy Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
>
>
> Demikhovsky, Elena wrote:
>
> > Even then, I'd personally want to see further evidence of why the
> correct solution is to model the floating point IV in SCEV rather than
> find a more powerful way of converting the IV to an integer that models
> > the non-integer values taken on by the IV. As an example, if the use
> case is the following code with appropriate flags to relax IEEE
> semantics so this looks like normal algabra etc:
>
> > for (float f = 0.01f; f < 1.0f; f += 0.01f) ç **A**
>
> ...
>
> > I'd rather see us cleverly turn it into:
>
> > float f = 0.01f;
>
> > for (int i = 1; i < 100; i += 1, f += 0.01f) ç **B**
>
> I can later try to enhance IndVarSimplify::handleFloatingPointIV() in
> order to convert**A** to **B**.
>
> But **B** is exactly the case I’m starting from. The main IV “i” is
> integer. The variable “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 *think* that that could be sufficient to handle case B.
>
>
>
> Then if we find other pressing cases to handle we can rethink the strategy.
>
>
>
> Also the current diagnostics is pretty bad for Hideki’s testcase with TTT
> as float.  This is what we currently report with
> -Rpass-analysis=loop-vectorize:
>
>
>
> /tmp/sss.c:3:6: remark: loop not vectorized: value that could not be
>
>       identified as reduction is used outside the loop
>
>       [-Rpass-analysis=loop-vectorize]
>
>
>
> I have no clue why we say that the value is used outside the loop.  I
> think this should just say that we have a loop-variant value that we
> couldn’t identify either as an induction or as a reduction.
>
>
>
> Adam
>
>
>
>
> If we're interested in handling complex variants of A directly: computing
> trip counts, proving away predicates etc. without translating the loops to
> use integer IVs (perhaps because we can't legally do so), then I can see
> FP-SCEV as a reasonable implementation strategy, but it looks like the
> general consensus is that such cases are rare and generally not worth
> optimizing?
>
> -- Sanjoy
>
>
>
> -*/Elena/*
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160520/fbd0783f/attachment.html>