search for: fremmed

Following simple program gives different answers when compiling with GCC (4.8.4) and ToT Clang: $ cat builtin_fmodf_bugpoint.cpp #include <cstdio> int main(int argc, char** argv) { const float a = 1.0f; const float b = 0.1f; printf("%f mod %f = %f\n", a, b, __builtin_fmodf(a, b)); return 0; } $ g++ -o builtin_fmodf_bugpoint_gcc builtin_fmodf_bugpoint.cpp $

%y = fadd float %x, undef Can we simplify this? Currently in IR, we do nothing for fadd/fsub/fmul. For fdiv/frem, we propagate undef. The code comment for fdiv/frem says: "the undef could be a snan" If that's correct, then shouldn't it be the same for fadd/fsub/fmul? But this can't be correct because we support targets that don't raise exceptions...and even targets

Hi, Consider the following test case: int foo(float *A, float *B, float *C, int len, int VSMALL) { for (int i = 0; i < len; i++) if (C[i] > VSMALL) A[i] = B[i] / C[i]; } In this test the div operation is conditional but llvm is generating unconditional div for this case: vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [

> > Do you have plans to add other intrinsics? I'm curious as to why there > > is an llvm.sin intrinsic and an llvm.cos intrinsic, but no llvm.atan > > intrinsic. Why is there an llvm.pow intrinsic but no llvm.log > > intrinsic? > > Intrinsics get added on demand. Generally there has to be a good reason > to add them. llvm.sin was implemented (for

Hi Guys, I found that FRem generates instruction *call 0* by JIT on windows 7, msvc 2010 sp1 x86, and llvm.exp.f32 also has this issue. My LLVM version is official 3.0. Anyone give me some tips ? Thanks a lot ! SALVIA Project Manager Ye WU http://code.google.com/p/softart -- Ye Wu CELL: +86 159 9957 0103 -------------- next part -------------- An HTML attachment was scrubbed... URL:

Here are some clarifications for the reference manual. Please verify that my assumptions are correct. Shall I post a patch? Floating-point Constants: Add "The assembler requires the exact decimal value of a floating-point constant. For example, the assembler accepts '1.25' but rejects '1.3' because '1.3' is a repeating decimal in binary." Binary

I’m not sure the transformation happening with fdiv is correct. If we have “%y = fdiv float %x, undef” and %x is a NaN then the result will be NaN for any value of the undef, right? So if I understand the undef rules correctly (never a certainty) then we can’t safely replace the expression with undef. We could, I think, replace it with “%y = %x” though. I think the same is true for fadd, fsub,

Yes, if %x is a NaN, we should expect that NaN is propagated. I'm still not sure what to do here. We can take comfort in knowing that whatever we do is likely an improvement over the current situation though. :) That's because the code in InstSimplify is inconsistent with the LangRef: http://llvm.org/docs/LangRef.html#undefined-values (UB for fdiv by 0?) ...and both of those are

Why is NaN “just ‘undef’ in IR”? NaN is a specific value with well-defined behavior. I would think that unless the no-NaNs flag is used we need to preserve the behavior of NaNs. From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Wednesday, February 28, 2018 12:08 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Nuno Lopes

Duncan Sands skrev: > Hi Xerxes, > > >> 4. softfloat related errors >> http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ >> example: >> >> root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc >>

On Tue, Nov 27, 2007 at 10:50:03AM -0700, Jon Sargeant wrote: > > > Do you have plans to add other intrinsics? I'm curious as to why there > > > is an llvm.sin intrinsic and an llvm.cos intrinsic, but no llvm.atan > > > intrinsic. Why is there an llvm.pow intrinsic but no llvm.log > > > intrinsic? > > > > Intrinsics get added on demand.

Correct - NaN is not undef in IR. But we don't have a NaN in this example. We have its moral equivalent in LLVM - an uninitialized value, undef. So we're not introducing any extra uncertainty by propagating the undef. The backend can choose whatever encoding of undef makes sense when lowering? And yes, I don't know why FP-div-by-zero would ever be UB. I think that text in the LangRef

I sent a long message yesterday describing a problem I thought had to do with the JIT stubs. After further investigating, the problem seems to be in the code generation. The following basic block seems to have an error in it's code generation: __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i,

What I’m saying is that if we have one operand that is not an undef value then that operand might be NaN and if it is then the result must be NaN. So while it may be true that we don’t have a NaN, it is not true that we definitely do not have a NaN in the example. This is analogous to the example in the language reference where it says “%A = or %X, undef” -> “%A = undef” is unsafe because any

Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to

I was reading various documents in the llvm/docs/ directory and found a few minor typos. I don't have write access so if someone could apply these for me, that would be great. --- Index: docs/LangRef.rst =================================================================== --- docs/LangRef.rst (revision 228410) +++ docs/LangRef.rst (working copy) @@ -368,7 +368,7 @@ The idea

I came across this comment in SelectionDAG.cpp: case ISD::FADD: case ISD::FSUB: case ISD::FMUL: case ISD::FDIV: case ISD::FREM: // If both operands are undef, the result is undef. If 1 operand is undef, // the result is NaN. This should match the behavior of the IR optimizer. That isn't intuitive to me. I would have expected a binary FP operation with one undef operand to

Howdy All, I''ve a bit of a strange problem here. I have a filesystem with one snapshot that simply refuses to be destroyed. The snapshots just prior to it and just after it were destroyed without problem. While running the zfs destroy command on this particular snapshot, the server becomes more-or-less hung. It''s pingable but will not open a new shell (local or via ssh) however

For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter

I'm pretty sure that isn't what nnan is supposed to mean. If the result of nnan math were undefined in the sense of "undef", programs using nnan could have undefined behavior if the result is used in certain ways which would not be undefined for any actual float value (e.g. converting the result to a string), which seems like a surprising result.  And I don't think we