firstprivate clause in <#pragma simd>

firstprivate clause in <#pragma simd>

The Cilk Plus spec says that for #pragma simd, the private, firstprivate, lastprivate, and reduction clauses are as OpenMP. However, in the OpenMP 4.0rc2 spec, the firstprivate clause is not valid in <#omp simd>.

Is the firstprivate clause valid for Cilk Plus' <#pragma simd>?

8 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

The Cilk Plus spec was written before OpenMP 4.0rc2.  It is supposed to refer to the OpenMP 3 specification for parallel loops.  However, this turned out to be a rather sloppy shortcut on our part.  Parallel for loops are described in terms of threads, whereas #pragma simd does not use threading.

For the time being, assume that firstprivate refers to the vector lane. (This is what is implemented in the icc compiler.) As we update the spec, we will harmonize these definitions with OpenMP 4, possibly deprecating firstprivate.

As I was told by a member of the compiler team, firstprivate and lastprivate are required in the current compilers when simd is applied to a situation where it is relevant.   I have several unanswered premier issues about cases where it works with one architecture target and fails with another.

I noticed in the last release that one of the cases I submitted no longer has simd causing failure on any architecture, but the correction appears to be that it is ignored for the target where it previously broke.

I haven't seen an explanation of what might be meant by "firstprivate refers to the vector lane."

So we still have the situation where pragma simd needs to be tested thoroughly for changes or breakage with new compiler updates.

I should have said the that private clauses refer to the iteration, rather than to the simd lane.  Each iteration gets a fresh copy of a private variable.  In the case of firstprivate, the private variable is initialized to the value it had outside of the loop.  At least, that's what icc implements.

Quote:

Pablo Halpern (Intel) wrote:

I should have said the that private clauses refer to the iteration, rather than to the simd lane.  Each iteration gets a fresh copy of a private variable.  In the case of firstprivate, the private variable is initialized to the value it had outside of the loop.  At least, that's what icc implements.

Thanks, this makes more sense.

If firstprivate and lastprivate are deprecated, it seems this will reinstate an obligation on the compiler to connect use of a variable inside a loop to use before and/or after, or to reject pragma simd if such usage occurs and can't be accommodated correctly.  I'd prefer to have a reason given when simd is rejected, as well as cutting down on silent acceptance when it will break the code.

Quote:

Pablo Halpern (Intel) wrote:

I should have said the that private clauses refer to the iteration, rather than to the simd lane.  Each iteration gets a fresh copy of a private variable.  In the case of firstprivate, the private variable is initialized to the value it had outside of the loop.  At least, that's what icc implements.

Hmmm, maybe I'm misunderstanding, but that does not seem to be what icc is doing:

houston:~$ cat b.c
int N=40;
int main()
{
int i;
int a;
#pragma simd private (a)
for (i = 0; i < N; ++i)
printf("%p\n", &a);
}
houston:~$ icc b.c
houston:~$ ./a.out | head
0x7fffffffc720
0x7fffffffc724
0x7fffffffc728
0x7fffffffc72c
0x7fffffffc720
0x7fffffffc724
0x7fffffffc728
0x7fffffffc72c
0x7fffffffc720
0x7fffffffc724

Am I missing something obvious here, or does the above look like there are private variables for each simd lane (every 4 items gets a fresh copy)?

Quote:

TimP (Intel) wrote:

If firstprivate and lastprivate are deprecated, it seems this will reinstate an obligation on the compiler to connect use of a variable inside a loop to use before and/or after, or to reject pragma simd if such usage occurs and can't be accommodated correctly.  I'd prefer to have a reason given when simd is rejected, as well as cutting down on silent acceptance when it will break the code.

I'm not sure what obligation you are talking about wrt firstprivate and lastprivate.  The compiler's obligation (or lack of obligation) to warn about buggy code is the same whether we have firstprivate or not.  BTW, lastprivate is not being deprecated, AFAIK.

Quote:

Aldy Hernandez wrote:

Am I missing something obvious here, or does the above look like there are private variables for each simd lane (every 4 items gets a fresh copy)?

I think you are misunderstanding the meaning of private.  The addresses must be different, or else they are not private in any sense.  That is why I said that each lane gets a fresh copy of the private variable. It is the initial value, not the address, that is reset at the beginning of each iteration.

-Pablo

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui