Michael Zolotukhin via llvm-dev
2016-May-17 01:20 UTC
[llvm-dev] Working on FP SCEV Analysis
> On May 16, 2016, at 5:35 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Sanjoy Das via llvm-dev" <llvm-dev at lists.llvm.org> >> To: escha at apple.com >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Michael V Zolotukhin" <michael.v.zolotukhin at intel.com> >> Sent: Monday, May 16, 2016 7:31:20 PM >> Subject: Re: [llvm-dev] Working on FP SCEV Analysis >> >> Hi Escha, >> >> via llvm-dev wrote: >>> One thought I’ve had about this in the past — >>> >>> SCEV is useful for proving two expressions are equivalent (in >>> general, >>> not just specifically for loop induction variables). This gets a >>> little >>> bit trickier with fast-math; for example, suppose two expressions >>> are >>> equivalent, but *only* with reassociativity allowed? >> >> This isn't too different from "sext(a + b) == sext(a) + sext(b) only >> if the addition is nsw". >> >> However, it wasn't clear to me from the lang-ref what the fastmath >> flags really mean. What is the semantics of a program that computes >> ((a +fast b) +fast c) when ((a + b) + c) != (a + (b + c))? > > This is often true, and it is neither UB nor poison. The user has given the compiler the freedom to choose whatever the compiler decides will be most-efficient to compute. "fast math" is an odd concept in that sense. It is giving the compiler the freedom to change the program semantics to some extent.It’s possible to make an infinite loop finite with fast math if the primary IV is float. Is it acceptable behavior too? What I mean is that if we have for (float i = 0.0; i < HUGE_FLOAT_NUMBER; i += 0.5) { ... } we might never reach HUGE_FLOAT_NUMBER, as at some point i+1.0 = i in float (or am I totally wrong here?). However, when analyzing this loop, we might find its trip count to be exactly HUGE_FLOAT_NUMBER*2. There are all kinds of odd stuff with floats in this area, but probably if ‘-ffast-math’ is provided, we’re fine. I’m also very interested in specific cases we want to catch here. In the past Tyler (CCed) looked into this problem, but as far as I remember we decided that complexity/gains ratio was too low. Basically, I anticipate that the code to support this in SCEV will be at least as sophisticated as for integers, but in contrast to integers FP induction variables are much rarer in real world programs, at least to my impression. Thanks, Michael> > -Hal > >> Does it >> have UB (in which case we can't hoist fastmath arithmetic) or is it >> more like poison? Depending on the answer, for fastmath we can >> considering doing what we do today for nuw/nsw (which has its own set >> of issues, but at least wouldn't require us to start from scratch). >> >> -- Sanjoy >> _______________________________________________ >> 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 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > 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 <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/20160516/62f030ea/attachment.html>
----- Original Message -----> From: "Michael Zolotukhin" <mzolotukhin at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Michael V Zolotukhin" > <michael.v.zolotukhin at intel.com>, "tyler nowicki" > <tyler.nowicki at gmail.com> > Sent: Monday, May 16, 2016 8:20:05 PM > Subject: Re: [llvm-dev] Working on FP SCEV Analysis> > On May 16, 2016, at 5:35 PM, Hal Finkel via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: >> > ----- Original Message ----- >> > > From: "Sanjoy Das via llvm-dev" < llvm-dev at lists.llvm.org > > > > > > > To: escha at apple.com > > > > > > Cc: "llvm-dev" < llvm-dev at lists.llvm.org >, "Michael V > > > Zolotukhin" > > > < > > > michael.v.zolotukhin at intel.com > > > > > > > Sent: Monday, May 16, 2016 7:31:20 PM > > > > > > Subject: Re: [llvm-dev] Working on FP SCEV Analysis > > >> > > Hi Escha, > > >> > > via llvm-dev wrote: > > >> > > > One thought I’ve had about this in the past — > > > > > >> > > > SCEV is useful for proving two expressions are equivalent (in > > > > > > > > > > general, > > > > > > > > > > not just specifically for loop induction variables). This gets > > > > a > > > > > > > > > > little > > > > > > > > > > bit trickier with fast-math; for example, suppose two > > > > expressions > > > > > > > > > > are > > > > > > > > > > equivalent, but *only* with reassociativity allowed? > > > > > >> > > This isn't too different from "sext(a + b) == sext(a) + sext(b) > > > only > > > > > > if the addition is nsw". > > >> > > However, it wasn't clear to me from the lang-ref what the > > > fastmath > > > > > > flags really mean. What is the semantics of a program that > > > computes > > > > > > ((a +fast b) +fast c) when ((a + b) + c) != (a + (b + c))? > > >> > This is often true, and it is neither UB nor poison. The user has > > given the compiler the freedom to choose whatever the compiler > > decides will be most-efficient to compute. "fast math" is an odd > > concept in that sense. It is giving the compiler the freedom to > > change the program semantics to some extent. >> It’s possible to make an infinite loop finite with fast math if the > primary IV is float. Is it acceptable behavior too? What I mean is > that if we have > for (float i = 0.0; i < HUGE_FLOAT_NUMBER; i += 0.5) { > ... > } > we might never reach HUGE_FLOAT_NUMBER, as at some point i+1.0 = i in > float (or am I totally wrong here?). However, when analyzing this > loop, we might find its trip count to be exactly > HUGE_FLOAT_NUMBER*2. There are all kinds of odd stuff with floats in > this area, but probably if ‘-ffast-math’ is provided, we’re fine.Great question. So, if I paraphrase the intent of "fast math" to be, "I'm only thinking about these floating-point numbers as real numbers, you can do the same", then I think the answer to your question is yes. Furthermore, that would certainly speed things up. ;)> I’m also very interested in specific cases we want to catch here. In > the past Tyler (CCed) looked into this problem, but as far as I > remember we decided that complexity/gains ratio was too low. > Basically, I anticipate that the code to support this in SCEV will > be at least as sophisticated as for integers, but in contrast to > integers FP induction variables are much rarer in real world > programs, at least to my impression.To be honest, I don't think that loops with a floating-point reduction variable, written as the loop counter, is common or worth much dedicated effort. I have seen this in real code, but it normally comes from people trying (perhaps too hard) to work around integer register pressure problems. The case that Elena presented, however:> float fp_inc; > > float x = init; > for (int i=0;i<N;i++){ > A[i] = x; > x += fp_inc; // Loop invariant variable or constant > }is not uncommon. Being able to do something intelligent with this is worthwhile. -Hal> Thanks, > Michael> > -Hal >> > > Does it > > > > > > have UB (in which case we can't hoist fastmath arithmetic) or is > > > it > > > > > > more like poison? Depending on the answer, for fastmath we can > > > > > > considering doing what we do today for nuw/nsw (which has its own > > > set > > > > > > of issues, but at least wouldn't require us to start from > > > scratch). > > >> > > -- Sanjoy > > > > > > _______________________________________________ > > > > > > LLVM Developers mailing list > > > > > > llvm-dev at lists.llvm.org > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >> > -- > > > Hal Finkel > > > Assistant Computational Scientist > > > Leadership Computing Facility > > > Argonne National Laboratory > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/d5c09f7a/attachment.html>
> On May 16, 2016, at 6:31 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To be honest, I don't think that loops with a floating-point reduction variable, written as the loop counter, is common or worth much dedicated effort. I have seen this in real code, but it normally comes from people trying (perhaps too hard) to work around integer register pressure problems. The case that Elena presented, however: > > > float fp_inc; > > > > float x = init; > > for (int i=0;i<N;i++){ > > A[i] = x; > > x += fp_inc; // Loop invariant variable or constant > > } > > is not uncommon. Being able to do something intelligent with this is worthwhile.Yes, we should handle floating-point reductions, not induction variables. Sorry if I misunderstood the intent. I thought that Tyler already solved the problem of vectorizing FP reductions though. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/caddf7d8/attachment.html>