similar to: [LLVMdev] help with pointer-to-array conversion

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 =

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

Hi I have the followed code for which I am writing a loop pass. int main() { int i = 0; for (i=0; i<20; i++) { printf ("hello world %d\n", i); } return 0; } In the function runOnLoop, I have the following instruction PHINode *indv = NULL; indv = L->getCanonicalInductionVariable(); However, when I check indv is always set to NULL. Since the code has a canonical

OK, thanks Chris, I've found that running opt -loopsimplify -instcombine -indvars -stats gives me the setup I need for this transformation, and a small patch makes it happen in the simple case we discussed. However, I'm having some trouble when things get a bit more complicated with 3 nesting levels: int A[3000000], B[20000], C[100], Z; int main() { int i, j, k, *a, *b,

On Thu, 21 Jul 2005, Naftali Schwartz wrote: >> If you're interested in dependence analysis, the next important step is > to >> start analyzing distance and direction vectors. > > Well, specifically, I was thinking of a mechanism to turn this: The indvars pass is *intentionally* restricted to only promoting affine expressions to array subscripts, not arbitrary

Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression,

Well, I guess I was hoping soemthing like this would help in the pointer-to-array transformation for the following code: > > int A[100], B[100], C[100], X, Y, Z; > > > > int *p_a = &A[0]; > > int *p_b = &B[0]; > > int *p_c = &C[0]; > > > > int i, j, k, f; > > for ( k = 0; k < Z; k++ ) > >

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. Well, specifically, I was thinking of a

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > 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. Hi

On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote: > I've landed the patch in r324449. > > Before we merge this into two different Clang release branches and > almost immediately release one of them, I would really like someone > to confirm that this patch works well with the Linux kernel. David, > if you're up for that, it would be great. Alternatively, Guenter

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth

I am new to LLVM and couldn't find any llvm-user list, so I am posting my user question here, sorry. I am trying to create a simple "puts" call accepting the static string, with the code below. The last line (CallInst::Create) fails with an assert: "Calling a function with a bad signature!" Because the type of function is void(u8*) and the argument supplied is:

I'm sorry, it had seemed to me that the documented functionality: // ConvertibleToGEP - This function returns true if the specified value V is // a valid index into a pointer of type Ty. If it is valid, Idx is filled in // with the values that would be appropriate to make this a getelementptr // instruction. The type returned is the root type that the GEP would point to would be quite

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > I'm sorry, it had seemed to me that the documented functionality: > > // ConvertibleToGEP - This function returns true if the specified value V is > // a valid index into a pointer of type Ty. If it is valid, Idx is filled in > // with the values that would be appropriate to make this a getelementptr > // instruction. The type

Hi Johannes, > Now that reasoning works from a conceptual standpoint only for > non-inbounds GEPs, I think. From a practical standpoint my above > description will probably make sure everything works out just fine (see > also my rephrased answer down below!). I say this because I think the > following lang-ref passage makes sure everything, not only memory > accesses, involving

On Aug 19, 2008, at 12:32 PM, David Greene wrote: > Are LoopPasses allowed to maintain state between runOnLoop > invocations? What kind of information are you looking to maintain between runOnLoop invocations ? > > The documentation is not clear on this point. doInitialization() and doFinalization() will be run for each pass before and after runOnLoop(). For each pass

Hi, >>> I see. Is there a quick answer to the questions why you need inbounds >>> GEPs in that case? Can't you just use non-inbounds GEPs if you know you >>> might not have a valid base ptr and "optimize" it to inbounds once that >>> is proven? >> >> You mean on the Rust side? We emit GEPi for field accesses and array indexing.

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.

On Tuesday 19 August 2008 15:15, Devang Patel wrote: > On Aug 19, 2008, at 12:32 PM, David Greene wrote: > > Are LoopPasses allowed to maintain state between runOnLoop > > invocations? > > What kind of information are you looking to maintain between runOnLoop > invocations ? Cached analysis answers. > > The documentation is not clear on this point. > >