similar to: [LLVMdev] Presenting Unsafe Math Flag to Optimizer

On Wed, Jan 13, 2010 at 4:20 PM, Bill Wendling <wendling at apple.com> wrote: > Hi all, > > A quick question: > > 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

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

On Jan 13, 2010, at 4:50 PM, Devang Patel wrote: > On Wed, Jan 13, 2010 at 4:20 PM, Bill Wendling <wendling at apple.com> wrote: >> Hi all, >> >> A quick question: >> >> 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.

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

> There are three options, that you mentioned off-line: > > A) Caller wins > This could result in something the programmer didn't expect, possibly > resulting in an incorrect answer. > > B) Don't inline > We potentially miss important optimizations. > > C) Safety first > The programmer could get code they didn't expect, but at least it won't

> 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

To continue the discussion I started last year (see the link below) on embedding command-line options in bitcode, I came up with a plan to improve the way the backend changes UnsafeFPMath on a per-function basis. The code in trunk currently resets TargetOptions::UnsafeFPMath at the beginning of SelectionDAGISel::runOnMachineFunction to enable compiling one function with “unsafe-fp-math=true” and

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

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

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

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

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

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

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:

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

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

Map the HIVEX_OPEN_UNSAFE flag into the libguestfs API and use it in various places. Rich.

Thanks Duncan, GVN/EarlyCSE worked as suggested. Any pointers on how to optimize out: %accumulate = fadd double %6, 0.000000e+00 Using the 3.1 release and the C++ API, I can't figure out how FPMathOperator, TargetOptions, nor IRBuilder::SetDefaultFPMathTag work. I also don't see any floating point math transformation passes. I did see IRBuilder::SetFastMathFlags, do I need to update to

Hi, Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule);