[llvm-dev] Working on FP SCEV Analysis

[Hal Finkel via llvm-dev]

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

 -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