icc compile errors

[newport_j]

Ihave a program thatI am tryng to compile with icc. I am adding cilk_for and redfining loop indexes to avoid some parallel errors.

Now theses errors arise:

expressionmust be modifiable lvalue

inner_Rint = (*Env).network.NtargetR;


expressionmust be modifiable lvalue

i=i=1;


expressionmust be modifiable lvalue

i=i=1;


How do I get hese to go away in icc comilation?

Thanks in advance.

Newport_j

[Judith_W_Intel]

Please post an actual compilable example. Howare i and inner_Rint declared? Are they const?

Judy

[Brandon_H_Intel]

Hi Newport_j,

I don't think that's legal. According to our User's Guide, cilk_for loops have the following restriction:

The loop control variable must not be modified in the loop body. The following form is not supported:

cilk_for (unsigned int i = 1; i < 16; ++i) i = f();

[newport_j]

Is there a work around for this? Or does that mean that there is no solution and do not cilkify that part of the code?

Thaks in advance.

Newport_j

[TimP]

If your parallel loop is to end conditionally before the count is up, instead of trying to exit, you skip over the body each time until the count is up:
_Cilk_for(i=0,done=0;i if(!done){
.....
}

[newport_j]

Please explain this last reply. I am interested in what you are saying .

If your parallel loop is to end conditionally before the count is up, instead of trying to exit, you skip over the body each time until the count is up:
_Cilk_for(i=0,done=0;i if(!done){
.....
}

I want to know more about this.

Thanks in advance.

Newport_j

[TimP]

As you still haven't given an example where we could show you the appropriate change, a fairly common idiom for combining 2 loops of different length is like:
count=max(lenA, lenB)
cilk_for(int i = 0; i < count; ++i){
if(i < lenA){
do A stuff
}
if i < lenB){
do B stuff
}
}
In such a case, there wouldn't be a prohibition against resetting lenA or lenB inside the loop; the loop would continue up to the original expected number of iterations, but would do nothing while running up the count when that is what you requested. Common obvious optimizations exist, for example if you assert lenA >= lenB you eliminate the inside condition on len and outside condition on lenB. You might expect the do-nothing iterations to take less time than thie others, but you might sitll have valuable paralllelization, particularly if the number of empty scopes is relatively small.