similar to: [LLVMdev] Bug in InstCombiner::FoldAndOfFCmps

On 11 April 2013 16:26, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Hey guys, > > I've come across a bug when combining an AND of FCMPs. This bug occurs in my > compiler as well as Clang built from trunk. > > A reduced test case is: > > int foo( float a, double b ) { > return (a == a) & (b == b); > } > > and the error is: > >

On 5/2/2013 4:20 PM, Rafael Espíndola wrote: > > I don't get any errors compiling this. Do you know if it was fixed? Do > you get an error only for some particular target? What is the 'clang > -cc1' command line that you seed in the error? I see this error in our compiler, but not with the trunk. I guess it's been fixed, but I don't know which commit did it.

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

Hi, Working on private backend, based on llvm-3.7 Inside lib/Transforms/InstCombine/InstCombineCompares.cpp there is attempt to optimize fabs: if (F->getIntrinsicID() == Intrinsic::fabs || ... switch (I.getPredicate()) { ... case FCmpInst::FCMP_OGT: return new FCmpInst(FCmpInst::FCMP_ONE, CI->getArgOperand(0), RHSC); But CI->getArgOperand(0)

On Thu, Nov 8, 2018 at 11:35 PM Fabian Giesen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What is so complicated about these? Shouldn't they just correspond to > two compares + selects? > > To give a concrete example, x86 MIN[SP][SD] and MAX[SP][SD], > respectively, correspond exactly to > > MIN*: select(a < b, a, b) (i.e. "a < b ? a : b")

Are the ICMP and FCMP instructions meant to accept vectors operands or no? Verifier excludes vectors, as does the AsmParser[1]. But the CmpInst constructor accepts vectors[2], and they are documented as allowed: > If the operands [of icmp or fcmp] are packed typed, the elements of > the vector are compared in turn and the predicate must hold for all > elements. — Gordon [1]

Hi everyone, I'm learning how to use LLVM API and JIT engine and I've come across with an issue I haven't been able to figure out. The problem I'm having is that the wrong float is being stored in a float global variable. The code snippet I use to generate the float value is as follow: llvm::Type* type = // initialize with the global variable type; std::string

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

Hi Gordon, On Fri, 2007-01-19 at 09:35 -0500, Gordon Henriksen wrote: > Are the ICMP and FCMP instructions meant to accept vectors operands or > no? No. > Verifier excludes vectors, as does the AsmParser[1]. Correct. > But the CmpInst constructor accepts vectors[2], At one time we tried to get them working, guess that's a left over. > and they are documented as

On Jul 21, 2009, at 11:14 PM, Eli Friedman wrote: > Testcase (compile with clang >= r76726): > #include <emmintrin.h> > __m128i a(__m128 a, __m128 b) { return a==a & b==b; } > > CodeGen ends up scalarizing the comparison, which is really bad, and > AFAIK different from what we did before vsetcc was removed. The ideal > code is a single cmpordps, although I

Reid Spencer wrote: > Hi Baptiste, > > On Fri, 2007-01-05 at 09:44 +0100, Baptiste Lepilleur wrote: >> I just want to make sure I understand the semantic of the icmp >> function correctly as assumption are dangerous in this domain. >> >> The syntax is specified as follow: >> <result> = icmp <cond> <ty> <var1>, <var2> ; yields

Hi Baptiste, On Fri, 2007-01-05 at 22:10 +0100, Baptiste Lepilleur wrote: > Reid Spencer wrote: > > Hi Baptiste, > > > > On Fri, 2007-01-05 at 09:44 +0100, Baptiste Lepilleur wrote: > >> I just want to make sure I understand the semantic of the icmp > >> function correctly as assumption are dangerous in this domain. > >> > >> The syntax is

Andy, Here is the left circular shift operator patch. I apologize to the reviewer in advance. The patch has a good bit of fine detail. Any comments/criticisms? Some caveats... 1) This is just the bare minimum needed to make the left circular shift operator work (e.g. no instruction combining). 2) I tried my best to select operator names in the existing style; please feel free to change them as

Hi LLVMdev, In the specification of llvm ir, the select operation can takes a condition of vector type, 'select' Instruction Syntax: <result> = select *selty* <cond>, <ty> <val1>, <ty> <val2> *; yields ty* *selty* is either i1 or {<N x i1>} Overview: The 'select' instruction is used to choose one value based on a condition,

This is indeed a bug. I get a different error on my machine. Until we solve this bug, as a workaround, you can use the <4 x float> type for which the vselect works. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Fan Dawei Sent: Wednesday, October 19, 2011 10:10 To: LLVMdev at cs.uiuc.edu Subject: [LLVMdev] Error when cond of select instruction is

Hi Rotem, What do you mean by "you can use the <4 x float> type for which the vselect works". Do you mean that then back-end can correctly split the operands when it is a four elements vector? I've try that, but it still fails. On Wed, Oct 19, 2011 at 4:21 PM, Rotem, Nadav <nadav.rotem at intel.com> wrote: > This is indeed a bug. I get a different error on my

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

Hi, I’m looking at what the LLVM compilation chain does to optimize the following functions using logical operators. The one using integer type (t1 and t3) are optimized, but not the ones using float type (t2 and t4), even when using -O3 or -Ofast. Why is that ? Thera are those kind of optimizations done in the LLVM source code? Thanks. bool t1(int v1) { return (2 + v1) == 7; } bool

> Nope, you want non-trapping instructions. If you use trapping > instructions, C99 functions like isgreater will not work correctly with > NAN's. How do I know when to use a trapping instruction? For example consider this C function: ------------------------ int f(float a, float b) { return a <= b; } ------------------------ gcc uses fcmpes instead of fcmps... >