Ristow, Warren via llvm-dev
2017-Oct-03 10:02 UTC
[llvm-dev] Trouble when suppressing a portion of fast-math-transformations
>>> 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? > > I don't know. I didn't see any definition of it. > > In my case I'm talking about allowing the use of lower precision but very fast machine > instructions instead of a slow sequence of inline instructions. But I guess instruction > vs library is equivalent.I haven't defined "libm" explicitly. The concept of "reassoc" and "libm" are a result of the discussion last November. The "libm" aspect in particular, came from: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html It was intended to mean actual library functions, which is what I thought you were referring to when you said "This option also relaxes the precision of commonly used math functions." From your elaboration describing it as a sequence of inline instructions, I think whether "libm" is the right flag to control it would depend on what that sequence of instructions were doing. If they were implementing 'pow()' or 'sqrt()' or 'sin()' etc., then yes, I think "libm" would be the right flag. If something else (unrelated to functions generally in libm), then probably some other flag (or set of flags) would control whether a transformation was done. More generally, my intended approach of doing this change (of removing the "fast" umbrella flag, and adding the two new flags "reassoc" and "libm"), is to audit all the places that currently enable an optimization based on whether ‘hasUnsafeAlgebra()’ is true (which essentially is asking whether _all_ the existing FastMathFlags are enabled), and see which of them can/should be controlled by one (or a subset of) the full set. So it's possible that a particular slow sequence of inline instructions you are transforming would be controlled by "libm", and a different slow sequence of inline instructions would be controlled by some other flag (or flags). -Warren From: bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] On Behalf Of Bruce Hoult Sent: Tuesday, October 3, 2017 10:05 AM To: Hal Finkel Cc: Ristow, Warren; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations On Tue, Oct 3, 2017 at 4:03 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote: -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? I don't know. I didn't see any definition of it. In my case I'm talking about allowing the use of lower precision but very fast machine instructions instead of a slow sequence of inline instructions. But I guess instruction vs library is equivalent. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/287a6cd1/attachment-0001.html>
Hal Finkel via llvm-dev
2017-Oct-03 16:13 UTC
[llvm-dev] Trouble when suppressing a portion of fast-math-transformations
On 10/03/2017 05:02 AM, Ristow, Warren wrote:> > >>> 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? > > > > > > I don't know. I didn't see any definition of it. > > > > > > In my case I'm talking about allowing the use of lower precision but > very fast machine > > > instructions instead of a slow sequence of inline instructions. But I > guess instruction > > > vs library is equivalent. > > I haven't defined "libm" explicitly. The concept of "reassoc" and > "libm" are a result of the discussion last November. The "libm" aspect > in particular, came from: > > http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html > > It was intended to mean actual library functions, which is what I > thought you were referring to when you said "This option also relaxes > the precision of commonly used math functions." From your elaboration > describing it as a sequence of inline instructions, I think whether > "libm" is the right flag to control it would depend on what that > sequence of instructions were doing. If they were implementing > 'pow()' or 'sqrt()' or 'sin()' etc., then yes, I think "libm" would be > the right flag. If something else (unrelated to functions generally > in libm), then probably some other flag (or set of flags) would > control whether a transformation was done. > > More generally, my intended approach of doing this change (of removing > the "fast" umbrella flag, and adding the two new flags "reassoc" and > "libm"), is to audit all the places that currently enable an > optimization based on whether ‘hasUnsafeAlgebra()’ is true (which > essentially is asking whether _all_ the existing FastMathFlags are > enabled), and see which of them can/should be controlled by one (or a > subset of) the full set. So it's possible that a particular slow > sequence of inline instructions you are transforming would be > controlled by "libm", and a different slow sequence of inline > instructions would be controlled by some other flag (or flags). >I agree. We should give the flags semantic meanings. Whether or not something is generally a function call is irrelevant. libm, if we use that name, refers to the functions in libm, and perhaps close extensions, regardless of how the target generally generates code for them. It might be clearer, instead of using 'libm', to use something like 'trans' (for transcendental functions). -Hal> -Warren > > *From:*bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] *On Behalf > Of *Bruce Hoult > *Sent:* Tuesday, October 3, 2017 10:05 AM > *To:* Hal Finkel > *Cc:* Ristow, Warren; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] Trouble when suppressing a portion of > fast-math-transformations > > On Tue, Oct 3, 2017 at 4:03 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote: > > -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? > > I don't know. I didn't see any definition of it. > > In my case I'm talking about allowing the use of lower precision but > very fast machine instructions instead of a slow sequence of inline > instructions. But I guess instruction vs library is equivalent. >-- 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/20171003/0e9149b9/attachment.html>
Ristow, Warren via llvm-dev
2017-Oct-04 09:32 UTC
[llvm-dev] Trouble when suppressing a portion of fast-math-transformations
> It might be clearer, instead of using 'libm', to use something like 'trans' (for transcendental functions).That does seem clearer. ‘trans’ is definitely good with me. -Warren From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Tuesday, October 3, 2017 5:13 PM To: Ristow, Warren; Bruce Hoult Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations On 10/03/2017 05:02 AM, Ristow, Warren wrote:>>> 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? > > I don't know. I didn't see any definition of it. > > In my case I'm talking about allowing the use of lower precision but very fast machine > instructions instead of a slow sequence of inline instructions. But I guess instruction > vs library is equivalent.I haven't defined "libm" explicitly. The concept of "reassoc" and "libm" are a result of the discussion last November. The "libm" aspect in particular, came from: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html It was intended to mean actual library functions, which is what I thought you were referring to when you said "This option also relaxes the precision of commonly used math functions." From your elaboration describing it as a sequence of inline instructions, I think whether "libm" is the right flag to control it would depend on what that sequence of instructions were doing. If they were implementing 'pow()' or 'sqrt()' or 'sin()' etc., then yes, I think "libm" would be the right flag. If something else (unrelated to functions generally in libm), then probably some other flag (or set of flags) would control whether a transformation was done. More generally, my intended approach of doing this change (of removing the "fast" umbrella flag, and adding the two new flags "reassoc" and "libm"), is to audit all the places that currently enable an optimization based on whether ‘hasUnsafeAlgebra()’ is true (which essentially is asking whether _all_ the existing FastMathFlags are enabled), and see which of them can/should be controlled by one (or a subset of) the full set. So it's possible that a particular slow sequence of inline instructions you are transforming would be controlled by "libm", and a different slow sequence of inline instructions would be controlled by some other flag (or flags). I agree. We should give the flags semantic meanings. Whether or not something is generally a function call is irrelevant. libm, if we use that name, refers to the functions in libm, and perhaps close extensions, regardless of how the target generally generates code for them. It might be clearer, instead of using 'libm', to use something like 'trans' (for transcendental functions). -Hal -Warren From: bruce.hoult at gmail.com<mailto:bruce.hoult at gmail.com> [mailto:bruce.hoult at gmail.com] On Behalf Of Bruce Hoult Sent: Tuesday, October 3, 2017 10:05 AM To: Hal Finkel Cc: Ristow, Warren; 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 On Tue, Oct 3, 2017 at 4:03 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote: -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? I don't know. I didn't see any definition of it. In my case I'm talking about allowing the use of lower precision but very fast machine instructions instead of a slow sequence of inline instructions. But I guess instruction vs library is equivalent. -- 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/20171004/9e8cc7b8/attachment.html>