[llvm-dev] Trouble when suppressing a portion of fast-math-transformations

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 2 18:03:53 PDT 2017



On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote:
> Is there anything that means, in particular, "go fast, even if it 
> means not all bits are significant"?
>
> I'm currently working on an llvm-based compiler for a GPU that is 
> optomised for OpenGL, where 16 bit FP may not be quite accurate enough 
> (or may be in some cases), but 32 bit FP is overkill. A lot of the 
> fast, built in, operations end up with a few junk bits at the end (not 
> add/sub/mul . but divide is available *only* using reciprocal).
>
> When implementing OpenCL, the specs and conformance tests require full 
> IEEE accuracy. In some cases this requires a round of Newton-Raphson 
> to clean up the accuracy, which is a significant though maybe not 
> crippling performance penalty. But in other cases we need to do a lot 
> of range reduction, some polynomial, and then generalise the result 
> again. This can be an order of magnitude or more slower than using the 
> not-quite-accurate-enough built in instruction.

This is what arcp is for (implying that you can use the reciprocal 
estimate and not worry about getting the exact answer). Now there's a 
separate question about how many Newton iterations to use, and we have a 
separate flag for that (-mrecip=...). Check out the implementation of  
TargetLoweringBase::getRecipEstimateSqrtEnabled to see how it's setup in 
backend. This is, however, per function, so we don't currently have a 
per-operation control on this.

>
> The OpenCL spec defines a number of compile flags controlling 
> optimizartions. Some seem to map well onto the flags already discussed 
> here:
>
> -cl-mad-enable
> -cl-no-signed-zeros
> -cl-finite-math-only
>
> However it looks to me that the following ones don't presently map 
> well to LLVM:
>
> -cl-unsafe-math-optimizations
> Allow optimizations for floating-point arithmetic that (a) assume that 
> arguments and results are valid, (b) may violate IEEE 754 standard and 
> (c) may violate the OpenCL numerical compliance requirements as 
> defined in the SPIR-V OpenCL environment specification for single 
> precision and double precision floating-point, and edge case behavior 
> in the SPIR-V OpenCL environment specification. This option includes 
> the -clno-signed-zeros and -cl-mad-enable options.

I think the idea is that this flag, like -funsafe-math-optimizations, 
gets mapped to an appropriate collection of finer-grained flags internally.

>
> -cl-fast-relaxed-math
> Sets the optimization options -cl-finite-math-only and 
> -cl-unsafe-math-optimizations. This allows optimizations for 
> floating-point arithmetic that may violate the IEEE 754 standard and 
> the OpenCL numerical compliance requirements for single precision and 
> double precision floating-point, as well as floating point edge case 
> behavior. This option also relaxes the precision of commonly used math 
> functions. This option causes the preprocessor macro 
> __FAST_RELAXED_MATH__ to be defined in the OpenCL program. The 
> original and modified values are defined in the SPIR-V OpenCL 
> environment specification
>
> I'd like to emphasise in the latter one: "This option also relaxes the 
> precision of commonly used math functions."

Isn't this the "libm" flag that is proposed in this thread?

  -Hal

>
>
> On Mon, Oct 2, 2017 at 4:45 PM, Ristow, Warren via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     I'm not aware of any additional bits needed.  But putting us right
>     at the edge leaves me uncomfortable.  So an implementation that
>     isn't limited by the 7 bits in SubclassOptionalData seems sensible.
>
>     Thanks,
>
>     -Warren
>
>     *From:*Sanjay Patel [mailto:spatel at rotateright.com
>     <mailto:spatel at rotateright.com>]
>     *Sent:* Monday, October 2, 2017 12:06 AM
>     *To:* Ristow, Warren
>     *Cc:* Hal Finkel; llvm-dev at lists.llvm.org
>     <mailto:llvm-dev at lists.llvm.org>
>     *Subject:* Re: [llvm-dev] Trouble when suppressing a portion of
>     fast-math-transformations
>
>     Are we confident that we just need those 7 bits to represent all
>     of the relaxed FP states that we need/want to support?
>
>     I'm asking because FMF in IR is currently mapped onto the
>     SubclassOptionalData of Value...and we have exactly 7 bits there. :)
>
>     If we're redoing the definitions, I'm wondering if we can share
>     the struct with the backend's SDNodeFlags, but that already has
>     one extra bit for vector reduction. Should we give up on
>     SubclassOptionalData for FMF? We have a MD_fpmath enum value for
>     metadata, so we could move things over there?
>
>     On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Hi Hal,
>
>     >> 4. To fix this, I think that additional fast-math-flags are likely
>     >> needed in the IR.  Instead of the following set:
>     >>
>     >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract'
>     >>
>     >> something like this:
>     >>
>     >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract'
>     >>
>     >> would be more useful.  Related to this, the current 'fast' flag
>     which acts
>     >> as an umbrella (enabling 'nnan' + 'ninf' + 'nsz' + 'arcp' +
>     'contract') may
>     >> not be needed.  A discussion on this point was raised last
>     November on the
>     >> mailing list:
>     >>
>     >>
>     http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html
>     <http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html>
>     >
>     > I agree. I'm happy to help review the patches. It will be best
>     to have
>     > only the finer-grained flags where there's no "fast" flag that
>     implies
>     > all of the others.
>
>     Thanks for the quick response, and for the willingness to review. 
>     I won't let
>     this languish so long, like the post from last November.
>
>     Happy to hear that you feel it's best not to have the umbrella
>     "fast" flag.
>
>     Thanks again,
>
>     -Warren
>     _______________________________________________
>     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>
>
>
>     _______________________________________________
>     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>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/b8c7e7f7/attachment.html>


More information about the llvm-dev mailing list