search for: fcmpinst

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) returns operand with type (double*) rather then double, because in our ABI doubles are passed via memory. Next assertion fires inside FCmpInst ctor: llvm::FCmpInst::FCmpIns...

...lt from trunk. A reduced test case is: int foo( float a, double b ) { return (a == a) & (b == b); } and the error is: Assertion failed: (getOperand(0)->getType() == getOperand(1)->getType() && "Both operands to FCmp instruction are not of the same type!"), function FCmpInst, file [snip]/clang/llvm/include/llvm/IR/Instructions.h, line 1117. We begin with a float "a" and double "b": > (fcmp oeq a, a) & (fcmp oeq b, b) After canonicalization in InstCombine, we end up with the expression: > (fcmp ord a, 0.0) & (fcmp ord b, 0.0) The...

...l values. + resize(Idx * 2 + 1); + } strange indentation +++ lib/Bitcode/Reader/BitcodeReader.cpp (Arbeitskopie) +void BitcodeReaderValueList::resize(unsigned Desired) { + if (Desired > Capacity) + { Please put brace on same line as if. - Constant *C= ConstantExpr::getFCmp(FCmpInst::FCMP_OEQ, - const_cast<Constant*>(CP1->getOperand(i)), - const_cast<Constant*>(CP2->getOperand(i))); + Constant *C = ConstantExpr::getFCmp(FCmpInst::FCMP_OEQ, + CP1->getOperand(i), +...

...hat's another reason, but not the main one. Optimizations only work with either floating point or integer arithmetic so it is useful to have two classes to distinguish the cases for example, code like: if (ICmpInst *ICI = dyn_cast<ICmpInst>(I)) { .. integer optimizations ... } else if (FCmpInst *FCI = dyn_cast<FCmpInst>(I)) { .. floating point optimizations ... } This idiom is used throughout LLVM. Since we treat them separately in the code, it is best to match that with separate instructions at the assembly level as well. > > >> [...] > > Yes. When you trunc...

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 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. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

...t; int foo( float a, double b ) { > return (a == a) & (b == b); > } > > and the error is: > > Assertion failed: (getOperand(0)->getType() == getOperand(1)->getType() && > "Both operands to FCmp instruction are not of the same type!"), function > FCmpInst, file [snip]/clang/llvm/include/llvm/IR/Instructions.h, line 1117. > 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? Cheers, Rafael

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 Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > 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. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

...NST(44, IntToPtr, IntToPtrInst) // Integer -> Pointer +HANDLE_CAST_INST(45, BitCast , BitCastInst ) // Type cast + LAST_CAST_INST(45) // Other operators... - FIRST_OTHER_INST(45) -HANDLE_OTHER_INST(45, ICmp , ICmpInst ) // Integer comparison instruction -HANDLE_OTHER_INST(46, FCmp , FCmpInst ) // Floating point comparison instr. -HANDLE_OTHER_INST(47, PHI , PHINode ) // PHI node instruction -HANDLE_OTHER_INST(48, Call , CallInst ) // Call a function -HANDLE_OTHER_INST(49, Select , SelectInst ) // select instruction -HANDLE_OTHER_INST(50, UserOp1, Instruction) // May be...

...T::Codegen() in ccHkdHVT.o PrototypeAST::Codegen() in ccHkdHVT.o PrototypeAST::Codegen() in ccHkdHVT.o FunctionAST::Codegen() in ccHkdHVT.o _main in ccHkdHVT.o __static_initialization_and_destruction_0(int, int)in ccHkdHVT.o "vtable for llvm::FCmpInst", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o "llvm::Type::getForwardedTypeInternal() const", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o BinaryExprAST::Codegen() in ccHkdHVT.o BinaryExprAST::Codegen() in ccHkdHVT....

...PrototypeAST::Codegen() in ccHkdHVT.o > PrototypeAST::Codegen() in ccHkdHVT.o > FunctionAST::Codegen() in ccHkdHVT.o > _main in ccHkdHVT.o > __static_initialization_and_destruction_0(int, int)in ccHkdHVT.o > "vtable for llvm::FCmpInst", referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > "llvm::Type::getForwardedTypeInternal() const", referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > BinaryExprAST::Codegen() in ccHkdHVT.o > BinaryExprAS...