[llvm-dev] Working on FP SCEV Analysis

[Hal Finkel via llvm-dev]

----- 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>