similar to: [LLVMdev] ICmpInst example?

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 iterator(i). What is the correct way todo something like this? void checkShadowPtr(Module &M,

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

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 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

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

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

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)

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

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

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, 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

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

[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

Hi Sanjay, thank you a lot for your answer. I understand that in your examples it is desirable that `foo` and `goo` are canonicalized to the same IR, i.e., something like `@goo`. However, I still have a few open questions, but please correct me in case I'm thinking in the wrong direction. > Am 21.07.2016 um 18:51 schrieb Sanjay Patel <spatel at rotateright.com>: > > I've

Should have changed the subject line... --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sergei Larin > Sent: Wednesday, July 03, 2013 12:29 PM > To: 'Tobias Grosser' > Cc: 'llvmdev'

Hi Sergei, On Thu, Jul 4, 2013 at 1:36 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Should have changed the subject line... > > --- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by > The Linux Foundation > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

On Fri, Aug 7, 2015 at 10:22 AM, Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > [Ooops, sent to the old list address by mistake] > > > > On 30 Jul 2015, at 21:04, tom at stellard.net wrote: > >> > >> For flags like

This might be hard cases making bad law, but the loop: void f (unsigned short *x, int *l) { int c = *l; int i; for (i = 0; i < c; i++) if (x[i]) x[i]++; } is converted to decrement-and-branch form by LoopStrengthReduce while: void f (unsigned short *x, int *l) { int i; for (i = 0; i < *l; i++) if (x[i]) x[i]++; } isn't.

I’ve almost finished a patch to add back in either out of line destructors or anchor methods. We seem to use one or the one, relatively inconsistently. What i’ve gone for is that if a class already had an inline destructor then i left it alone and added an anchor method. Otherwise I added an out of line destructor. Now if I compile Instructions.cpp with -Wweak-vtable, the only warnings given