Page 1 of 1

linear clause issues

PostPosted: Mon Mar 25, 2013 10:33 am
by jakub
From what I can understand on p147, "The value corresponding to the sequentially last iteration of the associated loops is assigned to the original list item.",
linear clause behavior is closer to lastprivate than plain private.
On p118 "If the canceled construct contains a reduction or lastprivate clause, the final value of the reduction or lastprivate variable is undefined."
Shouldn't this also talk about linear clauses (for the case of #pragma omp for simd or #pragma omp parallel for simd), while you can't cancel #pragma omp simd, one can cancel
#pragma omp for simd or #pragma omp parallel for simd?
On p122 we have "The loop iteration variable(s) in the associated for-loop(s) of a simd construct is (are) linear with a linear-step that is the increment of the associated loop."
Again, shouldn't this talk about simd or for simd or parallel for simd constructs? Also, could it be made clearer (probably also for the lastprivate wording) what exact value
is assigned for the linear or lastprivate iteration variables?
#pragma omp for lastprivate (i)
for (i = 0; i < 16; i++)
;
should set original list item i to 16, not 15 (i.e. value from last iteration after performing the IV increment). Similarly
#pragma omp simd linear (j, 2)
for (i = 0; i < 15; i += 2)
a[i] = j = i;
should assign to original i 16 and to original j 14. Also, on p124 it doesn't have exceptions for {,parallel }{,for }simd iteration variables, is that intentional that given those don't have
backwards compatibility, one isn't allowed to write
#pragma omp simd linear (i, 1)
for (i = 0; i < 16; i++)
;
?

Re: linear clause issues

PostPosted: Tue Mar 26, 2013 7:47 am
by jakub
Replying to myself on the following:
jakub wrote:On p118 "If the canceled construct contains a reduction or lastprivate clause, the final value of the reduction or lastprivate variable is undefined."
Shouldn't this also talk about linear clauses (for the case of #pragma omp for simd or #pragma omp parallel for simd), while you can't cancel #pragma omp simd, one can cancel

As "No OpenMP construct can appear in the simd region." the above is irrelevant, because #pragma omp cancel can't appear there either.

Re: linear clause issues

PostPosted: Thu Apr 11, 2013 4:11 am
by jakub
Just to double check, if linear clause is applied to variable with pointer type, is the actual linear step linear-step * sizeof (*ptr), or just linear-step? Say for int *ptr; linear(ptr : 4) is in Nth iteration ptr actually ptr + N * 4 or (int *) (((char *) ptr) + N * 4) ?

Also, what is supposed to happen if there is combined loop:
Code: Select all
#pragma omp parallel for simd linear(var, 16)
  for (i = 0; i < 1024; i++)
    ...

? As the linear clause description talks about the original list item being assigned some value, therefore it acts pretty much like listing the item in both firstprivate and lastprivate clauses, shall the above be parsed as:
Code: Select all
#pragma omp parallel firstprivate(var) lastprivate(var)
  #pragma omp for simd linear(var, 16)
    for (i = 0; i < 1024; i++)
      ...

i.e. must the original list item always have to be assigned even to the original list item of the parallel? There wouldn't be a way to say that the variable is linear in the simd loop, yet nothing after the loop uses the value (of course, the compiler can analyze the following code and optimize it away).

Also, as the iteration variable is predetermined linear rather than private in the simd loops, does that also mean that
Code: Select all
#pragma omp parallel for simd
  for (i = 0; i < 1024; i++)
    ...

must be treated as
Code: Select all
#pragma omp parallel lastprivate (i)
  #pragma omp for simd linear (i, 1)
    for (i = 0; i < 1024; i++)
      ...

? No firstprivate clause here, because clearly the iteration variable has to be initialized inside of the loop, so outer firstprivate doesn't make sense, but still compared to just #pragma omp parallel for where iteration variable is predetermined private and just optionally allowed to be specified in lastprivate clause it is more expensive by default.

Re: linear clause issues

PostPosted: Thu Apr 18, 2013 12:52 pm
by aduran
jakub wrote:should set original list item i to 16, not 15 (i.e. value from last iteration after performing the IV increment).
should assign to original i 16 and to original j 14.
Also, on p124 it doesn't have exceptions for {,parallel }{,for }simd iteration variables, is that intentional that given those don't have
backwards compatibility, one isn't allowed to write


You're correct in all cases

Re: linear clause issues

PostPosted: Thu Apr 18, 2013 12:56 pm
by aduran
jakub wrote:Just to double check, if linear clause is applied to variable with pointer type, is the actual linear step linear-step * sizeof (*ptr), or just linear-step? Say for int *ptr; linear(ptr : 4) is in Nth iteration ptr actually ptr + N * 4 or (int *) (((char *) ptr) + N * 4) ?


The increment as in the base language. So in this case would be linear-step * sizeof(*ptr)

You're also right in all the other descriptions that you make.

Re: linear clause issues

PostPosted: Fri Apr 19, 2013 4:22 am
by jakub
Thanks.

Another issue I came up on today. If loop iteration vars are predetermined linear, they should have linear semantics, but in collapsed loops with collapse 2 and above they certainly don't have such semantics.

Code: Select all
extern int a[13][13][13][13], k, l, m;

void
foo (float *p)
{
  int i, j, n, o;
  #pragma omp simd collapse (4) linear(k : m + 1)
  for (i = 0; i < 13; i++)
    for (j = 0; j < 13; j++)
      for (n = 0; n < 13; n++)
   for (o = 0; o < 13; o += 2)
     a[i][j][n][o] *= p[k], k += m + 1;
}


Here i, j, n and o should be predetermined linear, but none of them satisfy the rules, in the iteration of the combined loop none of these can be computed as start + step * iteration, all of them are like:
start + (((iteration / X) * step) % Y)
where start, step, X and Y are some integers computable before the loop.
So, perhaps shouldn't iteration vars be predetermined linear only in simd loops without collapse clause or with collapse(1)? For #pragma omp for simd the compiler will need to treat the iteration vars special (compute the initial values), but they certainly can't be treated like linear variables.

Re: linear clause issues

PostPosted: Wed Apr 24, 2013 4:48 pm
by xtian
J, N, O are not linear w.r.t to I-loop, J, N, O are private w.r.t to I-loop.

Re: linear clause issues

PostPosted: Thu Apr 25, 2013 3:57 am
by jakub
xtian wrote:J, N, O are not linear w.r.t to I-loop, J, N, O are private w.r.t to I-loop.


The collapse(4) clause says that all the 4 loops are collapsed together, into one loop that iterates 13*13*13*(13/2) times on this testcase, so there is no I loop and other loops.
So, either the standard should forbid the collapse clause on #pragma omp simd and say that it isn't allowed on #pragma omp for simd either, then all these issues are gone and in real-world not sure how often collapsed loops would be successfully vectorized, or the iterator vars can't be predetermined linear if collapse clause is present and is bigger than 1.
In the combined loop not even I, the outermost iterator, has linear behavior.

Re: linear clause issues

PostPosted: Thu Apr 25, 2013 9:30 am
by jakub
In the linear clause description the step doesn't have to be an integral constant expression, can be any integral expression, which is just fine in #pragma omp {,for,parallel for} simd, but for #pragma omp declare simd I wonder if it shouldn't be integral constant expression.