search for: i_3

...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 = xor i16 %T_2,...

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

...+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 > new value,...

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

...gt; > > > > > > > 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...

...ue the 'p' forms? If those p_j are ptrtoint to a i_j, and the computation for i is i = i_0 + i_1 + ... i_n, does it mean we can take either p_j as a base pointer, and other int variables its offset, say we take p_2 as the base pointer, and the p from i points to p_2 + (i_0 + i_1 + i_3 + .. i_n) ? So in the transformation example, the result is different when we take %196 or %193 as a base pointer. For alias-analysis, we may say the p can point to a memory any of the p_j points to. But if we consider memory safety, should we say p is safe to access if p is not out-of-bound no...

...gt; If those p_j are ptrtoint to a i_j, and the computation for i is i = > i_0 + i_1 + ... i_n, does it mean >  we can take either p_j as a base pointer, and other int variables > its offset, say we take p_2 as the base pointer, and the p from i > points to >       p_2 + (i_0 + i_1 + i_3 + .. i_n) >  ? > > So in the transformation example, the result is different when we take > %196 or %193 as a base pointer. > > For alias-analysis, we may say the p can point to a memory any of the > p_j points to. But if we consider memory safety, should we say p is > safe...

...If those p_j are ptrtoint to a i_j, and the computation for i is i = > i_0 + i_1 + ... i_n, does it mean > we can take either p_j as a base pointer, and other int variables > its offset, say we take p_2 as the base pointer, and the p from i > points to > p_2 + (i_0 + i_1 + i_3 + .. i_n) > ? So, in your example, if you do: i1 = ptrtoint p1; i2 = ptrtoint p2; ... in = ptrtoint pn; i = i1 + i2 ... + in; p = inttoptr i; ..., then p can point to any memory object p1, p2, ... pn. The reasoning is that the integer add instruction obscures which integer is the base...

...ptrtoint to a i_j, and the computation for i is i = >> i_0 + i_1 + ... i_n, does it mean >>  we can take either p_j as a base pointer, and other int variables >> its offset, say we take p_2 as the base pointer, and the p from i >> points to >>       p_2 + (i_0 + i_1 + i_3 + .. i_n) >>  ? >> >> So in the transformation example, the result is different when we take >> %196 or %193 as a base pointer. >> >> For alias-analysis, we may say the p can point to a memory any of the >> p_j points to. But if we consider memory safety, s...

...and the computation for i is i = >>> i_0 + i_1 + ... i_n, does it mean >>>  we can take either p_j as a base pointer, and other int variables >>> its offset, say we take p_2 as the base pointer, and the p from i >>> points to >>>       p_2 + (i_0 + i_1 + i_3 + .. i_n) >>>  ? >>> >>> So in the transformation example, the result is different when we take >>> %196 or %193 as a base pointer. >>> >>> For alias-analysis, we may say the p can point to a memory any of the >>> p_j points to. But if...

On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/4/2011 6:45 PM, Eli Friedman wrote: >> >> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> >>  wrote: >>> >>>> Hi, >>>> Is it correct to convert, >>>>   %196 = load i32* %195, align 8                

...for i is i = >>>> i_0 + i_1 + ... i_n, does it mean >>>>  we can take either p_j as a base pointer, and other int variables >>>> its offset, say we take p_2 as the base pointer, and the p from i >>>> points to >>>>       p_2 + (i_0 + i_1 + i_3 + .. i_n) >>>>  ? >>>> >>>> So in the transformation example, the result is different when we take >>>> %196 or %193 as a base pointer. >>>> >>>> For alias-analysis, we may say the p can point to a memory any of the >>&gt...

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =