similar to: [LLVMdev] Re: a few llvm questions, not time-critical

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for ( a =

I have a single c++ file that contains a class and a "wrapper" function that has C-like syntax for interacting with the Class. Basically, this wrapper function just makes an instance of the class and then organizes the data for return to R. #include <math.h> void myFunc(double *data, int *n, double *prm, double* intervals, int* max, double *plot) { ... } myClass::myclass(...)

Hi all, We have some code in Hexagon that needs to be run on MC instructions, as well as on MI instruction. Here is some background for why we have this need: Some Hexagon instructions can be converted to a more compact bit representation, with the exact same functionality, if the properties of its operands meet certain criteria. Thus on the MI layer, we check the properties of the

I think I understood the problem you're trying to solve. I didn't, however, understand the problems you are having (maybe you're not running mem2reg?). I do have a little piece of code that I think does (more or less) what you want. Take a look at it, try understanding it, and see if it helps you out. You might have to change it a bit since you're replacing uses after an

void MetaSplit::handleProgramUses(Value *V){ if(!isa<BasicBlock>(V)) programValues.insert(V); if(User *U = dyn_cast<User>(V)){ User::op_iterator OB = U->op_begin(), OE = U->op_end(); for(; OB != OE; ++OB){ if(CallInst *CI = dyn_cast<CallInst>(*OB)){ Function *F = CI->getCalledFunction(); if(F == ii || F == fi || F == vi || F == di || F == ci

Thanks for the reply. For the source code: int main() { int a = 0; int *p; p = &a; call_arnamoy(p); int *p1; p1 = p; return 1; } The bit code: %retval = alloca i32, align 4 %a = alloca i32, align 4 %p = alloca i32*, align 8 %p1 = alloca i32*, align 8 store i32 0, i32* %retval store i32 0, i32* %a, align 4 store i32* %a, i32** %p, align 8 %0 = load i32** %p, align 8 %call = call i32

On Apr 16, 2008, at 2:50 AM, heisenbug wrote: > > And now here is my educated speculation: > There are 2 things that became slower > 1) Use::getUser() > 2) Use::get/set due to tagging. > > The former is seldom called: > > $ find lib -name "*.cpp" | xargs grep "getUser(" | wc -l > 41 The majority of those aren't actually Use::getUser, but

Hello all, I wanted to get some feedback on this patch for ScalarEvolution. It addresses a performance problem I am seeing for simple benchmark. Starting with this C code: 01: signed char foo(void) 02: { 03: const int count = 8000; 04: signed char result = 0; 05: int j; 06: 07: for (j = 0; j < count; ++j) { 08: result += (result_t)(3); 09: } 10: 11: return result; 12: } I

On Wed, 23 Jun 2004, Patrick Meredith wrote: > Somehow it fails with operand out of bounds when the number of operands > is 2 and I am asking for the second operand. Second meaning operand 1. Okay, so you have something like this: if (CallInst *CI = dyn_cast<CallInst>(...)) { ... = CI->getOperand(1); } Can you send in this snippet of code, the assertion, and the

On Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with

https://bugs.freedesktop.org/show_bug.cgi?id=96656 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mesa-dev at lists.freedesktop. |nouveau at lists.freedesktop.o |org |rg QA

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

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

On Jun 21, 2013, at 10:18 AM, David Blaikie wrote: > On Fri, Jun 21, 2013 at 10:13 AM, Manman Ren <mren at apple.com> wrote: >> >> More details please :] >> What do you mean by "name the metadata"? Are you referring to the name field >> of the MDNode? > > Using named metadata rather than unnamed metadata. > > rather than having: > >

On Fri, Jun 21, 2013 at 10:13 AM, Manman Ren <mren at apple.com> wrote: > > More details please :] > What do you mean by "name the metadata"? Are you referring to the name field > of the MDNode? Using named metadata rather than unnamed metadata. rather than having: !llvm.hardref = !{metadata !"foo.h::myClass", !3, metadata !"bar.h:myEnum", !4} ...

Sorry about the tardiness of my reply. My mail client has playing tricks with me. :-) I am assuming the issue has nothing to do the branch to jumptable instructions but rather the MachineJumpTableInfo associated with every MachineFunction? If so, please take a look at BranchFoldiing.cpp for an example. Evan On Aug 10, 2007, at 12:30 PM, Fernando Magno Quintao Pereira wrote: > >

Hi all, I have a pass to break critical edges of Machine Basic Blocks, but I just discovered a bug (when compiling code for x86). The problem is 'jumpl *%reg'. I don't know how to update the jump table for this type of instruction. The code that I had (see below) does not update the jump table, and the actual branch keeps jumping to the old basic block, instead of the new.

Hi all, I wrote code that compiled with llvm 2.8, but now I'm using llvm 2.9 and it doesn't compile anymore: My code looks like this: User *U; ... if (PHINode * phi = dyn_cast<PHINode>(U)) { ... BasicBlock * Pred = phi->getIncomingBlock(I); ... } And when I compile it with clang: Live.cc:130:27: error: member access into