similar to: [LLVMdev] insert ICmpInst/BranchIns in Pass?

On Tue, Oct 11, 2011 at 7:22 PM, ret val <retval386 at gmail.com> wrote: > In a pass I would like to insert a ICmpInst/BranchInst pair to check > if 2 GlobalVariables are equal or not. If they are not I would like to > call a function. I've tried splitting the current block and then > inserting before the existing instructions, but for some reason this > seems to ruin the

I'm trying to come up with a simple example of using ICmpInst in a Pass. On each of the branches(true, false) I'd like to call a separate function and then resume(to the code that was already there). In this example i is a inst_iterator to Instruction the Pass is currently on. Now it segfaults opt before I can even get a dump() on it. Does anyone see what I am doing wrong? BasicBlock

On Tue, Sep 27, 2011 at 7:28 PM, ret val <retval386 at gmail.com> wrote: > I'm trying to come up with a simple example of using ICmpInst in a > Pass. On each of the branches(true, false) I'd like to call a separate > function and then resume(to the code that was already there). > > In this example i is a inst_iterator to Instruction the Pass is > currently on. Now

Hello ! I want some piece of advice regarding a LLVM pass. My particular problem is: There is a method bool patternDC::runOnFunction(Function &F) { ... if ( CC->operEquiv(icmpInstrArray[i], icmpInstrArray[j]) ) {...} ... } having the array elements of type Instruction* : http://llvm.org/doxygen/classllvm_1_1Instruction.html The called method is bool

I am looping through all instructions in a Function and depending on what I found I may or may not insert code. Despite the fact that I'm only actually inserting *before* instruction I have a infinite loop when I do something like below. For awhile it was simple enough to just increment i enough times but now I need something better. for(inst_iterator i = inst_begin(F); i != inst_end(F); ++i)

Be careful about oversimplifying signed integer comparisons -- integer arithmetic can easily overflow, so you cannot transform A > B to A - B > 0. The compare instructions in most processors do not simply subtract and test the most significant bit; they compute what the sign of the difference would be in extended precision. On Apr 17, 2010, at 1:00 PM, llvmdev-request at cs.uiuc.edu wrote:

Hi, i am playing the ScalarEvolution these days. i found the the ScalarEvolution will simply return a SCEVUnknow for a ICmpInst, so i think maybe great to add a new kind of SCEV to the ScalarEvolution framework. for example, if i run ScalarEvolution on the bc file generate from the following C source file: int f(int a, int b, int c, int d) { return (2 * a + 5 * c + 2) > (4 * d - 3*b

On Mon, Aug 29, 2011 at 12:38 PM, ret val <retval386 at gmail.com> wrote: > I am looping through all instructions in a Function and depending on > what I found I may or may not insert code. Despite the fact that I'm > only actually inserting *before* instruction I have a infinite loop > when I do something like below. For awhile it was simple enough to > just increment i

I'm having an issue with the Stubs used by the JIT Compiler. I'm not sure if it's a bug or if I'm doing something incorrectly. I've got a long complicated function with the following basic blocks at the end of it (The complete .ll file is attached): falseBlock: ; preds = %__exp.exit340 ret int 617 codeRepl: ; preds = %__exp.exit340

This addition converts strlen() calls to strnlen() when the result is compared to a constant. For example, the following: strlen(s) < 5 Becomes: strnlen(s, 5) < 5 That way, we don't have to walk through the entire string. There is the added overhead of maintaining a counter when using strnlen(), but I thought I'd start with the general case. It may make sense to only use this

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not

Chris Lattner wrote: > On Fri, 23 Apr 2004, Vladimir Prus wrote: > > and since result of *it is considered to be rvalue it can't be accepted > > by this operator. The complete discussion is in > > > > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm > > > > I'd suggest to apply the following patch which makes operator* return >

Hi all: I am trying 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)

On Mon, Jun 15, 2015 at 10:50 AM, mats petersson <mats at planetcatfish.com> wrote: > It will iterate over the instructions in the order that they are stored in > the module/function/basicblock that they belong to. And that SHOULD, > assuming llvm-dis does what it is expected to do, be the same order. > Thanks for the reply. What about instruction ordering across basic blocks?

Hi all, I have a question regarding a transformation that is carried out in InstCombine, which has been introduced by r48715. It unfolds expressions of the form `zext(or(icmp, (icmp)))` to `or(zext(icmp), zext(icmp)))` to expose pairs of `zext(icmp)`. In a subsequent iteration these `zext(icmp)` pairs could then (possibly) be optimized by another optimization (which has already been there before

On 6/16/15 1:09 AM, Nick Lewycky wrote: > Anirudh Sivaraman wrote: >> On Mon, Jun 15, 2015 at 10:50 AM, mats >> petersson<mats at planetcatfish.com> wrote: >>> It will iterate over the instructions in the order that they are >>> stored in >>> the module/function/basicblock that they belong to. And that SHOULD, >>> assuming llvm-dis does

On Fri, 23 Apr 2004, Vladimir Prus wrote: > Yea, I've noticed that. However, it looks like inst_iterator is iterator over > pointers. Oh, wait a minite, that's the current code: > > inline IIty operator*() const { return BI; } > inline IIty operator->() const { return operator*(); } > > So operator* works as if value_type is Instruction*, but operator->

Hi Sanjay, > Am 02.08.2016 um 21:39 schrieb Sanjay Patel <spatel at rotateright.com>: > > Hi Matthias - > > Sorry for the delayed reply. I think you're on the right path with D22864. No problem, thank you for your answer! > If I'm understanding it correctly, my foo() example and zext_or_icmp_icmp() will be equivalent after your patch is added to InstCombine.

Hello, I think there's a rather subtle problem with the inst_iterator. It declares its iterator category as std::bidirectional_iterator_tag but C++ standard requirements for forward iterator (which are included in requirements for bidirection iterator), say that the type of expression *r; should be T&, where 'r' is the iterator and T is its value type. The inst_iterator,

[Ooops, sent to the old list address by mistake] On 30 Jul 2015, at 21:04, tom at stellard.net wrote: > > For flags like -fno-rtti (are there others?) that are required in some cases > (I think -fno-rtti is required only if you sub-class LLVM objects), I would propose > adding a separate flag like --uses-rtti. This would give users more fine-grained > control over which flags