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)? 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. >
> > > 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? > > Just to explicitly not include myself in that consensus: I'm withholding areal view till I see *some* evidence one way or the other. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/186d45d4/attachment.html>
Hi, Daniel Berlin wrote: > > 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? > > Just to explicitly not include myself in that consensus: I'm withholding > a real view till I see *some* evidence one way or the other. Actually, allow me to revise what I said: "but it looks it isn't clear that such cases generally worth optimizing?" instead of "but it looks like the general consensus is that such cases are rare and generally not worth optimizing?" In any case, I wasn't trying to have a strong opinion on whether A is important or not, but was really trying to get at this: my intuition is that an FP-enabled SCEV will be worth the effort only if we ultimately want to make LLVM "handle complex variants of A directly". I wouldn't to make SCEV smarter around FP (which will be a lot of work, and add complexity through the analysis) and then stop at just B, since I don't see why we'd need all of the simplification etc. SCEV typically does if we just want to handle B-like cases. I may be wrong about the latter part, and if I am, I'd like to know what teaching SCEV about FP enables you to do in cases like B that are difficult to do without FP-SCEV. -- Sanjoy
> 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/736d8953/attachment-0001.html>
Demikhovsky, Elena via llvm-dev
2016-May-19 14:03 UTC
[llvm-dev] Working on FP SCEV 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.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*. - 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<mailto:llvm-dev at lists.llvm.org>> wrote: Demikhovsky, Elena wrote:> Even then, I'd personally want to see further evidence of why thecorrect 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 usecase 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<mailto: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/20160519/ef8d1e56/attachment.html>