search for: i_1

Hi. If I have a vector, v_1, and another vector of positive integers, i_1, the same length as v_1, then rep(v_1,i_1) will repeat v_i[j] exactly i_1[j] times, like so: >rep(c(1,2,3),c(3,2,1)) [1] 1 1 1 2 2 3 > I'd like to do the same sort of thing where I replace v_1 with a matrix, and the jth row of the matrix is repeated i_1 times. Obviously, I could do...

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

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

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

...uppose an int value 'i' is computed by a lot of int variables that are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i to a point p, how should I decide which pointer value 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...

Great, thanks! How much work do you think it will take to bring it up to date with the LLVM IR, except *ignoring* first-class structs and arrays for now? I believe llvm-gcc does not generate those in most cases and we can do a lot without supporting those. What else is missing relative to the current LLVM IR? Thanks, --Vikram Associate Professor, Computer Science University of

...;i'  is computed by a lot of int variables that > are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i > to a point p, how should I decide which pointer value 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 differe...

...;i' is computed by a lot of int variables that > are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i > to a point p, how should I decide which pointer value 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 your example, if you do: i1 = ptrtoint p1; i2 = pt...

...by a lot of int variables that >> are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i >> to a point p, how should I decide which pointer value 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 ex...

...sible in 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 origin...

...iables that >>> are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i >>> to a point p, how should I decide which pointer value 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) >>>  ? >>> >>>...

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                

...>> are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i >>>> to a point p, how should I decide which pointer value 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) >>>>  ? >&...

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 =

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

Dear all, I just stumbled over the fact that subsetting by square bracket will only output the first given index. I guess the rest is thrown away by the CADDR in RenderSub (plotmath.c l. 1399). Maybe changing this could be considered as "low-priority desired" (would be nice if the output works for ? However, I suggest to announce the fact that only the first parameter is printed in

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