search for: i_2

I have written test.ll as below and ran 'opt' on it as " opt -std-compile-opts test.ll -S -o -" . But the output shows that there is code motion around the barrier intrinsics. test.ll ------- ; ModuleID = 'test.bc' define void @test(i16* %I_0, i16* %I_1, i16* %I_2, i16* %I_3, i16* %O_0) { entry: %T_0 = load volatile i16* %I_0 %T_1 = load volatile i16* %I_1 %T_2 = load volatile i16* %I_2 %T_3 = load volatile i16* %I_3 call void @llvm.nvvm.barrier0() %T_5 = add i16 %T_1, %T_3 call void @llvm.nvvm.barrier0() %T_7 = mul i16 %T_0, %T_2 %T_8 = xo...

...x=&A[i+1]; > >> } > > > > This is not what it looks like in LLVM. > > In LLVM, it looks like this: > > std::vector<int> A(100); >> int* x,y; >> > >> > x_1=GEP A, 0, 0 >> > for(int i=0; i<100; i++) { >> > i_2 = phi (0, i_3) > x_2 = phi(x_1, x_3) > y_1 = GEP A, 0, i_2 > temp = load x_2 > store y_1, temp > temp2 = add i_2, 1 > x_3 = GEP A, 0, temp2 > i_3 = add i_2, 1 > } > > As you can see, every time you redefine the value of the pointer x to a &g...

is there any guarantee that the nvptx intrinsic "llvm.nvvm.barrier0" will not be moved around by opt ? In other words, can I expect all the instructions above "llvm.nvvm.barrier0" to remain above it and those below it to remain below, after all the opt passes are run ? If that is not the case, is there a way to define such an intrinsic ? Thanks. -------------- next part

On Thu, Aug 14, 2014 at 6:37 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Wed, Aug 13, 2014 at 8:35 PM, Jeremy Salwen <jeremysalwen at gmail.com> wrote: >> Hey Daniel, >> >> Thanks again for the help. I'm still a bit confused about the interface to >> the alias analysis. It seems like we are talking about different >> interfaces. >

...t; > > > > > > > > > > std::vector<int> A(100); > > > > int* x,y; > > > > > > > > > > > > > > > > > > x_1=GEP A, 0, 0 > > > > > > > > for(int i=0; i<100; i++) { > > i_2 = phi (0, i_3) > > x_2 = phi(x_1, x_3) > > y_1 = GEP A, 0, i_2 > > temp = load x_2 > > store y_1, temp > > temp2 = add i_2, 1 > > x_3 = GEP A, 0, temp2 > > i_3 = add i_2, 1 > > } > > > > > > As you can see, every time you redefine th...

...case of affine expressions used as GEP indices. I assume, GEP indices (except indexing into struct) are interpreted as signed integers. It isn't explicitly stated in the LangRef, but the code seems to treat them this way. Am I correct? If the result of an affine expression: a_1*i_1 + a_2*i_2 + ... + a_n*i_n is interpreted as signed value during the program run, it should be safe to assume during the program analysis that all operations (coefficients) are signed - signed evaluation of such an expression will bring the same result as evaluation of the expression using original signedn...

>However, there is one issue I have ignored - possibility of overflow in >the index expression. Suppose, we have such a loop: > for (i8 i = 0; i != 200; ++i) { > A[2 * i + 5] = ... > ... = A[2 * i + 3] > } >If both index expressions are evaluated in 8-bit arithmetic, >then the dependence equation should be solved in modular arithmetic: > 2 * i + 5 == 2 * (i +

I wrote some functions for multiway CANDECOMP, i.e. for least squares fitting of a_{i_1\cdots i_m}\approx\sum_{s=1}^p x^1_{i_1s}x^1_{i_1s}\cdots x^m_{i_ms} with arrays of arbitrary dimension. Reminded me of the good old APL days. I could not find this in the archives, but if it's already there, I would appreciate if someone let me know.

On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >> I'm definitely interested in improving coalescing and it sounds like >> this would fall under that work. Do you have references to papers >> that talk about the various algorithms? > > Some suggestions: > > @InProceedings{Budimlic02, > AUTHOR = {Zoran Budimlic and Keith D. Cooper and Timothy