similar to: [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level

Hi Micheal, On Mon, Oct 29, 2012 at 4:34 PM, Michael Ilseman <milseman at apple.com> wrote: > I > Flags > --- > no NaNs (N) > - ignore the existence of NaNs when convenient > no Infs (I) > - ignore the existence of Infs when convenient > no signed zeros (S) > - ignore the existence of negative zero when convenient > Does this mean ignore the possibility

On Fri, Nov 2, 2012 at 1:07 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > On Fri, Nov 2, 2012 at 10:02 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org> wrote: >> >> On 11/2/2012 11:53 AM, Michael Ilseman wrote: >>> >>> >>> >>> I think Dan was making two points with his example. Dan, correct me if I >>>

Revision 2 Revision 2 changes: * Add in separate Reciprocal flag * Clarified wording of flags, specified undefined values, not behavior * Removed some confusing language * Mentioned optimizations/analyses adding in flags due to inferred knowledge Revision 1 changes: * Removed Fusion flag from all sections * Clarified and changed descriptions of remaining flags: * Make 'N' and

Michael, Since you won't be using metadata to store this information and are augmenting the IR, I'd recommend incrementing the bitcode version number. The current version stored in a local variable in BitcodeWriter.cpp:1814* I would suspect then you'll also need to provide additional logic for reading: switch (module_version) { default: return Error("Unknown

I think I missed what problem we're trying to solve here. I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from

On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > I think I missed what problem we're trying to solve here. > > I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing

On Nov 12, 2012, at 10:39 AM, Joe Abbey <jabbey at arxan.com> wrote: > Michael, > > Since you won't be using metadata to store this information and are augmenting the IR, I'd recommend incrementing the bitcode version number. The current version stored in a local variable in BitcodeWriter.cpp:1814* > > I would suspect then you'll also need to provide

Here's a new version of the RFC, incorporating and addressing the feedback from Krzysztof, Eli, Duncan, and Dan. Revision 1 changes: * Removed Fusion flag from all sections * Clarified and changed descriptions of remaining flags: * Make 'N' and 'I' flags be explicitly concerning values of operands, and producing undef values if a NaN/Inf is provided. *

On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com> wrote: > Here's a new version of the RFC, incorporating and addressing the feedback > from Krzysztof, Eli, Duncan, and Dan. > > > Revision 1 changes: > * Removed Fusion flag from all sections > * Clarified and changed descriptions of remaining flags: > * Make 'N' and

Hi Michael, > Flags > --- > no NaNs (N) > - ignore the existence of NaNs when convenient > no Infs (I) > - ignore the existence of Infs when convenient > no signed zeros (S) > - ignore the existence of negative zero when convenient while the above flags make perfect sense for me, the other two seem more dubious: > allow fusion (F) > - fuse FP operations

On Oct 30, 2012, at 1:46 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Michael, > >> Flags >> --- >> no NaNs (N) >> - ignore the existence of NaNs when convenient >> no Infs (I) >> - ignore the existence of Infs when convenient >> no signed zeros (S) >> - ignore the existence of negative zero when convenient > > while

On Oct 30, 2012, at 4:19 PM, Dan Gohman <dan433584 at gmail.com> wrote: > On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com> wrote: > Here's a new version of the RFC, incorporating and addressing the feedback from Krzysztof, Eli, Duncan, and Dan. > > > Revision 1 changes: > * Removed Fusion flag from all sections > * Clarified and

On 10/29/2012 6:34 PM, Michael Ilseman wrote: > > N: no NaNs - ignore the existence of NaNs when convenient Maybe distinguish between quiet and signaling NaNs? > NI - no infs AND no NaNs > x - x ==> 0 > Inf > x ==> true Inf * x ==> 0? I think that if an infinity appears when NI (or I) is given, the result should be left as "undefined".

On Wed, Nov 14, 2012 at 7:19 PM, Michael Ilseman <milseman at apple.com> wrote: > I see now that it's only binary operators that have OptimizationFlags > reserved for them in the bitcode. Adding fast-math flags for only binary ops > is straight-forward, but adding them for other ops might require a more > involved bitcode change. ... > Given all that, I think it makes

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "James Molloy" <James.Molloy at arm.com>, "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" > <aschwaighofer at apple.com>, "LLVM Dev" <llvm-dev at

Hi all, This is about https://reviews.llvm.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'):

On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <hfinkel at anl.gov> wrote: > Andy, thanks for writing this up. A few thoughts: > > 1. The mental model that I have is that there is always an FP_CONTRACT pragma: there's some default (implicit) pragma at the beginning, and what it says (off/on/fast) is controlled by the command-line flags (or the driver's default if no flags

On Sun, 15 Apr 2012 02:00:37 +0400 Dmitry Babokin <babokin at gmail.com> wrote: > On Sun, Apr 15, 2012 at 1:02 AM, Duncan Sands <baldrick at free.fr> > wrote: > > > Hi Dmitry, > > > > > > The kinds of transforms I think can reasonably be done with the > > current > >> information are things like: x + 0.0 -> x; x / constant

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Warren Ristow" <warren.ristow at sony.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, November 15, 2016 11:10:48 PM > Subject: Re: [llvm-dev] RFC: Consider changing the semantics of > 'fast' flag implying all fast-math-flags > Hi,

Hi Dmitry, > The kinds of transforms I think can reasonably be done with the current > information are things like: x + 0.0 -> x; x / constant -> x * (1 / constant) if > constant and 1 / constant are normal (and not denormal) numbers. > > > The particular definition is not that important, as the fact that this > definition exists :) I.e. I think we need a