search for: nsz

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

* Sanjay Patel <spatel at rotateright.com> [2019-10-08 08:07:10 -0400]: > On Tue, Oct 8, 2019 at 7:08 AM Szabolcs Nagy <nsz at port70.net> wrote: > > why is that ok? > > > > Because there are no FP exceptions/signals for this IR opcode: > http://llvm.org/docs/LangRef.html#floating-point-environment so llvm cannot support an iso c frontend on an ieee754 target? (or fortran for that matter)

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 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...

...lto: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' > >> > >> woul...

...all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': arcp => "Allow optimizations to use the reciprocal of an argument rather than perform division.&...

...ren 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 'f...

...up disabling almost all the fast-math transformations. This causes a performance hit for people that have been doing this. 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...

...04> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. From a bitcode perspective, this change looks like this: Before r317488 we had 6 bits that respectively represented: UnsafeMath nnan ninf nsz arcp contract *unset* (The order may not match what is exactly in the bitcode.) After r317488 we had 7 bits that respectively represented: reassoc (-UnsafeMath- is gone) nnan ninf nsz arcp contract *afn* (new bit) Before r317488, fast-math was true if UnsafeMath was true (this should also imply...

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not available URL: <http://lists.l...

...all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': arcp => "Allow optimizations to use the reciprocal of an argument rather than perform division.&...

Trying to apply patches.. What's your base revision? Joe On Nov 15, 2012, at 5:44 PM, Michael Ilseman <milseman at apple.com> wrote: > New patches with review feedback incorporated: > * Changed single letter flags to short abbreviations ('S' ==> 'nsz') > * Indentation fixes > * Comments don't state function names > > <0002-Fast-math-flags-added-to-FPMathOperator.patch> > <0003-Fast-math-interfaces-for-Instructions.patch> > <0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> > <0005-...

...lla UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Be...

...UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Befor...

...UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Befor...

...to expand them a bit 'nnan', 'inf', etc.? They definitely need to be documented. > I think it does make sense to expand them to be more readable. Also, the textual representation doesn't have to precisely follow the internal names. What about: nnan : no nans ninf : no infs nsz : no signed zeros ar: allow reciprocal fast : unsafe algebra (and implicitly all the others) I'll get started on documentation. > Evan > > On Nov 15, 2012, at 10:17 AM, Michael Ilseman <milseman at apple.com> wrote: > >> Attached are some patches for adding in an IR-...

...> > What's your base revision? > > Joe > > On Nov 15, 2012, at 5:44 PM, Michael Ilseman <milseman at apple.com> wrote: > >> New patches with review feedback incorporated: >> * Changed single letter flags to short abbreviations ('S' ==> 'nsz') >> * Indentation fixes >> * Comments don't state function names >> >> <0002-Fast-math-flags-added-to-FPMathOperator.patch> >> <0003-Fast-math-interfaces-for-Instructions.patch> >> <0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.pa...

...it, but since this is very new to me, I can easily imagine I'm missing the big picture. > > For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags <http://llvm.org/docs/LangRef.html#fast-math-flags>) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': > > arcp => "Allow optimizations to use the reciprocal of an argument rather > than pe...

...lla UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Be...

...trinsics, > Clang *always* emit the "fast" attribute for all FP operations, and > that such scalarisation phase would split *all* non-fast FP > operations > if the target has non-IEEE-754 compliant SIMD. To be clear, I'm recommending that you add flags like nnan, ninf and nsz. However, I think that I've changed my mind: This won't work for the intrinsics. The flags are defined as: nsz No Signed Zeros - Allow optimizations to treat the sign of a zero argument or result as insignificant. nnan No NaNs - Allow optimizations to assume the arguments and resu...

...an', 'inf', etc.? They definitely need to be documented. >> > > I think it does make sense to expand them to be more readable. Also, the textual representation doesn't have to precisely follow the internal names. What about: > nnan : no nans > ninf : no infs > nsz : no signed zeros > ar: allow reciprocal > fast : unsafe algebra (and implicitly all the others) These seem reasonable to me. Thanks! Evan > > I'll get started on documentation. > >> Evan >> >> On Nov 15, 2012, at 10:17 AM, Michael Ilseman <milseman at...