search for: cmpinst

Hello, In one of the loop transformations I am developing, I need to convert eq and neq loop latch condition into less than or greater than depending on the control flow. The problem is that CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither signed nor unsigned in LLVM. Also, I did not find a way to find out if the integer operands of the CmpInst are signed or unsigned. Apparently, LLVM does not distinguish in its type system between signed and unsigned variables. So, I am not able to generate...

...ion-directory/lib. I am compiling example files for Kaleidoscope with following command : clang++ -g toy.cpp -std=c++11 `llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy but it fails with following error: Undefined symbols for architecture x86_64: "llvm::CmpInst::CmpInst(llvm::Type*, llvm::Instruction::OtherOps, llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::Instruction*)", referenced from: llvm::IRBuilder<true, llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true> >::CreateFCmp(llvm::CmpInst...

...s analysis and provides the conservative logic for when pointers are not equal. The only really problematic part would be InlineCost.cc, since that could try to replace NoAlias/ByVal arguments with allocas in the same function. For the moment, the inline cost estimation doesn't use the SimplifyICmpInst interface and there are other parts that need to be carefully validated before it can. It doesn't look too bad to add an explicit argument whether interprocedural analysis is being done and restrict the tests for that, but I am leaving this out as it is currently unnecessary. I am also not doi...

...erg -------------- next part -------------- Index: lib/Analysis/InlineCost.cpp =================================================================== --- lib/Analysis/InlineCost.cpp (revision 172366) +++ lib/Analysis/InlineCost.cpp (working copy) @@ -484,6 +484,8 @@ } bool CallAnalyzer::visitICmp(ICmpInst &I) { + // Do not just call SimplifyICmpInst as it can result in undefined + // changes when the operands involve NoAlias or ByVal arguments. Value *LHS = I.getOperand(0), *RHS = I.getOperand(1); // First try to handle simplified comparisons. if (!isa<Constant>(LHS)) Index: lib...

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] % llvm-as <<'EOT' >/dev/null d...

...o implementing reduceLoopCount for our TargetInstrInfo, we found that we didn't have enough information from analyzeLoop to reduce the loops. Currently the signatures look like this: bool analyzeLoop(MachineLoop &L, MachineInstr *&IndVarInst, MachineInstr *&CmpInst) unsigned TargetInstrInfo::reduceLoopCount(MachineBasicBlock &MBB, MachineInstr *IndVar, MachineInstr &Cmp, SmallVectorImpl<MachineOperand> &Cond, SmallVectorImpl<MachineInstr *> &PrevInsts, unsigned Iter, unsign...

...ome some trouble with LLVM 3.8... I built it with GCC 4.8.2 with cmake and no special CXX/C flags. That means in case of GCC that RTTI is switched on, I believe. However, building my MCJIT application against the just built LLVM and linking results in: libqdp.a(qdp_llvm.o):(.rodata._ZTIN4llvm8FCmpInstE[_ZTIN4llvm8FCmpInstE]+0x10): undefined reference to `typeinfo for llvm::CmpInst' libqdp.a(qdp_jit_util.o):(.rodata._ZTIN4llvm16ExtractValueInstE[_ZTIN4llvm16ExtractValueInstE]+0x10): undefined reference to `typeinfo for llvm::UnaryInstruction' libqdp.a(qdp_jit_util.o):(.rodata._ZTIN4llvm...

...Codegen() in ccHkdHVT.o "llvm::ConstantExpr::getSub(llvm::Constant*, llvm::Constant*)", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o "llvm::Instruction::~Instruction()", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o llvm::CmpInst::~CmpInst()in ccHkdHVT.o llvm::CmpInst::~CmpInst()in ccHkdHVT.o llvm::CallInst::CallInst<__gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocator<llvm::Value*> > > >(llvm::Value*, __gnu_cxx::__normal_iterator<llvm::Value**, std::vec...

On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the

On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: > > Is that > > assumption violated if I explicitly cast away const and pass the result > > to a function with NoAlias argument? > > Not immediately, no. It means that you can't access the constant > pointer's pointee directly within the noalias argument's scope. Access > to that object must go

..."llvm::ConstantExpr::getSub(llvm::Constant*, llvm::Constant*)", > referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > "llvm::Instruction::~Instruction()", referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > llvm::CmpInst::~CmpInst()in ccHkdHVT.o > llvm::CmpInst::~CmpInst()in ccHkdHVT.o > llvm::CallInst::CallInst<__gnu_cxx::__normal_iterator<llvm::Value**, > std::vector<llvm::Value*, std::allocator<llvm::Value*> > > >> (llvm::Value*, __gnu_cxx::__normal_iterator&lt...

How do you determine if a shift is signed or not? ashr = always signed? lshr = always unsigned? shl = always signed? The CmpInst has the "isSigned()" function, but it appears that every other Instruction I've looked at doesn't seem to have this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120222/9412d20c/attachmen...

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 allowed: > > > > If the operands [of icmp or fcmp] are packed typed, the elements of > > the vector are compared in turn and the predicate m...

On Mon, May 4, 2015 at 2:19 PM, Nicholas White <n.j.white at gmail.com> wrote: >> It's not quite the same testcase. > Yes - it's an extension of the first test case that I'd expect to be > optimised out in the same way as my earlier example (i.e., store a > value, read it back and branch on it). If you miss out the > "check.first.array.element" block

...ags they use, and also would let them choose the correct > flag since, for example, -fno-rtti is not understood by MSVC. There appears to be a regression in LLVM 3.7, which means that you must compile with -fno-rtti if you include llvm’s Instructions.h. The issue is that a few of the classes (ICmpInst, GetElementPtrInst and PHINode) are now defined entirely in the header, so every compilation unit that includes the header will emit them. These classes all inherit from Instruction (indirectly via CmpInst in the case of ICmpInst) and so fail to link if compiled with -fno-rtti, because they can’t...

...rying to compare the return value of a call instruction with 0. The called function's return type is uint32. The return value is 1 or 0. But the icmp instruction cannot be created. CallInst *ret = CallInst::Create(ptr_func, params.begin(), params.end(), "", bb); Value *cmp = new ICmpInst(*bb, ICmpInst::ICMP_EQ, ret, ,ConstantInt::get(getIntegerType(32), 0) "") The runtime error is: /usr/local/include/llvm/Instructions.h:690: llvm::ICmpInst::ICmpInst(llvm::BasicBlock&, llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, const llvm::Twine&): Assertion `getOperand...

...if a shift is signed or not? > > ashr = always signed? Essentially, yes. > lshr = always unsigned? Essentially, yes. > shl = always signed? Signed left shift and unsigned left shift are both shl. http://llvm.org/docs/LangRef.html#i_shl describes the semantics of shifts. > The CmpInst has the "isSigned()" function, but it appears that every other > Instruction I've looked at doesn't seem to have this. There isn't an isSigned() function because the query doesn't really make sense. LLVM IR doesn't in general track whether a value is signed or uns...

Hi all, I have checked in the API change for the classes BinaryOperator, CmpInst and CastInst, that upper- cases all methods that begin with "create". As announced (<http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-May/ 014636.html>) the legacy API is still in place. If you observe something to the contrary, please alert me and I shall fix it. Please note that...

...> Essentially, yes. > >> lshr = always unsigned? > > Essentially, yes. > >> shl = always signed? > > Signed left shift and unsigned left shift are both shl. > > http://llvm.org/docs/LangRef.html#i_shl describes the semantics of shifts. > >> The CmpInst has the "isSigned()" function, but it appears that every >> other >> Instruction I've looked at doesn't seem to have this. > > There isn't an isSigned() function because the query doesn't really > make sense. LLVM IR doesn't in general track whet...

Sorry, I'm a bit confused by your reply. I think part of my problem is I can only think of this in terms of Passes. For instance, my pass looks for assignments and tries to use the same pointer operand, before the assignment it finds. Like this: new ICmpInst(*block, CmpInst::ICMP_NE, shadow, store->getPointerOperand(), "Shadow check"); So I'm not sure how alloca could help me, seems like it wouldn't be a valid Value * for me to pass in at that point. Am I missing something? Thank you On Mon, Sep 19, 2011 at 2:02 PM, John Criswel...