similar to: [LLVMdev] unsafe math

On Jan 14, 2010, at 2:01 AM, Duncan Sands wrote: > Hi Bill, > >> The current implementation of the "allow unsafe math" option is to >> specify it via the TargetOptions object. However, this prevents the >> target-independent optimizer from using it. Are there any opinions >> (ha!) on how this could be achieved in a nice clean manner which >>

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 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

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

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

> This is actually really easy to do, the big issue is defining the > 'bits' that we want to carry on each operation. For example, I think > it would be reasonable to have an "assume finite" bit (saying no > nan's / inf), it would also be useful to know you can do reassociation > etc, useful to know that you don't care about signed zero, etc. I think the

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

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

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

Introduction --- LLVM IR currently does not have any support for specifying fine-grained control over relaxing floating point requirements for the optimizer. The below is a proposal to extend floating point IR instructions to support a number of flags that a creator of IR can use to allow for greater optimizations when desired. Such changes are sometimes referred to as fast-math, but this

Hi llvm-dev! We are doing some fuzzy testing using C program generators, and one question that came up when generating a program with both floating point arithmetic and loop pragmas was; Is the loop vectorizer really allowed to vectorize a loop when it can't prove that it is safe to reorder fp math, even if there is a loop pragma that hints about a preferred width. When reading here

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 Sat, Apr 14, 2012 at 11:44 PM, Duncan Sands <baldrick at free.fr> wrote: > > I think you have a step in the right direction, walking away from ULPs, >> which >> are pretty useless for the purpose of describing allowed fp optimizations >> IMHO. >> But using just "fast" keyword (or whatever else will be added in the >> future) is >> not

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

Hi Bill, > The current implementation of the "allow unsafe math" option is to specify it via the TargetOptions object. However, this prevents the target-independent optimizer from using it. Are there any opinions (ha!) on how this could be achieved in a nice clean manner which doesn't require using the TargetOptions object in the optimizer? a flag on each floating point

Hello dev, I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn't we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do

Hal, Thanks for the reply. I am trying to understand the underlying concern. That means the inlining of a callee without unsafe-fp-math attribute set will block the unsafe optimization in its caller, right? Thanks, Yan From: Finkel, Hal J. [mailto:hfinkel at anl.gov] Sent: Tuesday, December 4, 2018 11:34 AM To: Yan Luo <yan.luo2 at synopsys.com>; llvm-dev at lists.llvm.org Subject: Re:

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 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