similar to: [LLVMdev] llvm.sqrt and undefined behavior

Using the following example program #include <math.h> double f(double d){ return sqrt(d); } and compiling it with "clang -O3 ...", I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a sqrtsd instruction inline. It turns out that it could do exactly that, were it not for the fact that in the function

Hi all, I have the following test case: #define FLT_EPSILON 1.19209290E-7 int err = -1; int main() { float a = 8.1; if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am using FLT_EPSILON to check whether (a != 2.0). err = 1; } else { err = 0; } return 0; } with -O3 optimization level clang generates already incorrect LLVM IR: ; Function Attrs:

On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > Using the following example program > > #include <math.h> > > double f(double d){ > return sqrt(d); > } > > and compiling it with “clang –O3 …”, I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a

Hi, It looks like SimplifyLibCalls has a tendency to emit calls to libm functions without checking with TLI whether these calls are available. For example, PowOpt has this code: struct PowOpt : public UnsafeFPLibCallOptimization { PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {} virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B)

On Tue, Aug 13, 2013 at 5:58 AM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > Hi,**** > > ** ** > > It looks like SimplifyLibCalls has a tendency to emit calls to libm > functions without checking with TLI whether these calls are available.**** > > For example, PowOpt has this code:**** > > ** ** > > struct PowOpt : public

On Apr 16, 2012, at 11:50 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Dan, > >> I realize that some of these thoughts apply equally to the >> prior !fpaccuracy metadata that's been around a while, but I >> hadn't looked at it closely until now. >> >> The !fpmath metadata violates the original spirit of >> metadata, which is that

Hello, I have been gone for a while, finishing work on my Master's thesis... Now that I'm back I updated LLVM to the most recent version and found that my FP_ABS SelectionDAGNode type and code generation was now conflicting with the new FABS node type. I brought the rest of my local modifications in line with the FABS implementation, so here is my patch that includes sqrt, sin and cos

I am having a little trouble with the fcmp one instruction on doubles only. For ordered comparisons, the LLVM manual states that true should be returned iff neither operands is QNAN. ( http://llvm.org/docs/LangRef.html#i_fcmp) If I do fcmp one which includes one or both operands as a NaN, the result is expected to be 0 then. If I run the bitcode with lli (JIT off), no problem. If I use the

Chris Lattner wrote: > The patches I didn't apply are these: > > 1. Match (Y < 0) ? -Y : Y -> FABS in the SelectionDAGISel.cpp file. We > already catch this at the DAG level. If we aren't, please let me know. OK, no problem - I was just told last time I tried to get my patch in that this was needed because the C++ frontend generated this code, I'm generating

Are you able to send any IR for others to reproduce this issue? On Wed, Jul 17, 2013 at 11:23 PM, Peter Newman <peter at uformia.com> wrote: > Unfortunately, this doesn't appear to be the bug I'm hitting. I applied > the fix to my source and it didn't make a difference. > > Also further testing found me getting the same behavior with other SIMD > instructions.

On Thu, 28 Apr 2005, Morten Ofstad wrote: > I have been gone for a while, finishing work on my Master's thesis... Hi Morten, congrats! :) > Now that I'm back I updated LLVM to the most recent version and found > that my FP_ABS SelectionDAGNode type and code generation was now > conflicting with the new FABS node type. I brought the rest of my local > modifications in

FYI. http://leonardo-m.livejournal.com/73732.html If anyone is motivated, please file bugs for the losing cases. Also, it might make sense to incorporate the tests into our nightly tester test suite. Thanks, Evan

We've got both an sqrtf and an expf opcode in our architecture. If I call sqrt() on the C side, I see the sqrtf opcode show up in the generated assembly. However, if I call exp() on the C side, I don't see the expf opcode show up on the generated assembly, I see a call to an exp function from libm. Here's what we've got in our TargetInstrinfo.td file for both of these

Unfortunately, this doesn't appear to be the bug I'm hitting. I applied the fix to my source and it didn't make a difference. Also further testing found me getting the same behavior with other SIMD instructions. The common factor is in each case, ECX is set to 0x7fffffff, and it's an operation using xmm ptr ecx+offset . Additionally, turning the optimization level passed to

MipsOptimizeMathLibCalls.cpp converts: g = sqrt (f); into: r1 = sqrt (f) readonly; if (g is a NaN) r2 = sqrt (f); g = phi (r1, r2) I'd like to do the same on z. Would it be OK to make this pass generic and do the transformation whenever FSQRT isLegalOrCustom for the type? If so, should it stay a separate pass, or should I merge it with something else? Thanks, Richard

After writing a simple FPRange, I've hit a stumbling block. I don't know what LLVM code should be extended to use it. I was initially thinking of extending LazyValueInfo, but it appears to be used for passes that don’t address the case that I need for Julia. I’m now wondering if I’m better off extending SimplifyFCmpInst to handle the few cases in question instead of trying to be more

On Tuesday 16 December 2008 01:03:36 Evan Cheng wrote: > FYI. http://leonardo-m.livejournal.com/73732.html > > If anyone is motivated, please file bugs for the losing cases. Also, > it might make sense to incorporate the tests into our nightly tester > test suite. FWIW, I just ported my ray tracer benchmark to C and found that llvm-gcc gives much worse performance than gcc on x86

I've attached the module->dump() that our code is producing. Unfortunately this is the smallest test case I have available. This is before any optimization passes are applied. There are two separate modules in existence at the time, and there are no guarantees about the order the surrounding code calls those functions, so there may be some interaction between them? There shouldn't

Hi all, I'm working on a language in which I would like all operations to be well defined. (and efficient) I want to define a sqrt function in my language, that will return NaN for arguments < 0, and NaN for a NaN argument. As far as I know, these semantics map nicely to the SQRTPS SSE instruction, which seems to return NaN on arguments < 0. However, the LLVM lang ref states

> I strongly disagree with this proposal. The purpose of this general > purpose intrinsic is to expose sqrt functionality present on many of > the architectures LLVM supports. If we defined its edge cases, we > won't be able to map it to target functionality freely on targets whose > edge cases don't match that definition. I agree the targets should be the primary focus,