search for: setdefaultfpmathtag

...ath accuracy not a positive number!", &I); To be pedantic for a moment, zero is not a positive number. What about asserting these individually to give us more clear asserts if they fire? That also makes the string easier to write: "fpmath accuracy is a negative number!". + /// SetDefaultFPMathTag - Set the floating point math metadata to be used. + void SetDefaultFPMathTag(MDNode *FPMathTag) { DefaultFPMathTag = FPMathTag; } This should be 'setDefault...' much like 'getDefault...' above. + Instruction *AddFPMathTag(Instruction *I, MDNode *FPMathTag) const { Another bad...

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 3.2 and use this call? -- View this message in context: http://llvm.1065342.n5.nabble.com/Which-transform-passes-to-apply-tp52111p52211.html Sent from the LLVM...

...erts if they fire? That also makes > the string easier to write: "fpmath accuracy is a negative number!". It will fire on: zero, negative numbers, NaN, +-infinity. Personally I reckon "fpmath accuracy not a positive number!" is reasonable for all of these. > > + /// SetDefaultFPMathTag - Set the floating point math metadata to be used. > + void SetDefaultFPMathTag(MDNode *FPMathTag) { DefaultFPMathTag = FPMathTag; } > > This should be 'setDefault...' much like 'getDefault...' above. The rest of IRBuilder uses a capital S in its setters, so I was just tr...

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

Hi Josh, On 03/12/12 02:58, Josh Klontz wrote: > Hello, I'm a new LLVM user working on a C++ EDSL for image processing. I have > a function, which after applying createInstructionCombiningPass() and > createDeadCodeEliminationPass() looks like: > ... > *%dst_yRem = urem i32 %i, %dst_columns > %dst_y = urem i32 %i, %dst_columns > %1 = sub i32 %i, %dst_y >

...n 3.2 I think it will only be done by codegen (llc). The situation should be better in 3.3 since a bunch of fast-math support started going in to the IR level transforms. > > 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 3.2 and use this call? Please open a bug report since even in mainline this transform isn't done yet (as fast-math support at the IR level only just...

Hello, I'm a new LLVM user working on a C++ EDSL for image processing. I have a function, which after applying createInstructionCombiningPass() and createDeadCodeEliminationPass() looks like: define void @jitcv_sum_64sf1001(%Matrix* %src, %Matrix* %dst, i32 %len) { entry: br label %loop_i loop_i: ; preds = %loop_i_end, %entry %i = phi i32 [ 0,

The attached patch is a first attempt at representing "-ffast-math" at the IR level, in fact on individual floating point instructions (fadd, fsub etc). It is done using metadata. We already have a "fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata