Displaying 4 results from an estimated 4 matches for "__fast_relaxed_math__".
2017 Oct 03
2
Trouble when suppressing a portion of fast-math-transformations
...rd 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 th...
2017 Oct 03
2
Trouble when suppressing a portion of fast-math-transformations
...ay 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...
2017 Oct 04
2
Trouble when suppressing a portion of fast-math-transformations
...ay 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...
2017 Oct 02
2
Trouble when suppressing a portion of fast-math-transformations
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]
Sent: Monday, October 2, 2017 12:06 AM
To: Ristow, Warren
Cc: Hal Finkel; llvm-dev at lists.llvm.org
Subject: Re: