On 01/08/2014 02:46 PM, Iyer, Balaji V wrote:
+ /* Grain value, only used by _Cilk_for. */
+ tree grain;
Why can't the grain stay as a clause for the gimple form of the loop?
+ if (flag_enable_cilkplus && TREE_CODE (for_stmt) == CILK_FOR)
+ {
+ tree it = TREE_VEC_ELT (OMP_FOR_INIT (for_stmt), 0);
+ gimplify_and_add (it, &for_pre_body);
+ }
Why doesn't the normal handling of OMP_FOR_INIT work for Cilk? All the
special cases for CILK_FOR need comments explaining why they are needed.
Also, this seems like you're assigning to the control variable outside
of the loop, which doesn't makes sense because we initialize it in each
of the invocations of the child function. Right?
+ /* Original initial, final and increment values are necessary to compute
+ the loop-count. Otherwise, they are stored in variables and their
+ context could be changed, potentially making it impossible to compute
+ them correctly. */
I don't understand. Surely all you care about is the value, and
gimplification shouldn't affect that.
+ /* If VAR is the induction variable of the outer _Cilk_for, then
+ it needs to be passed as a value not pointer since it
+ would not be overwritten by the body. */
Here it looks like you're overriding the normal logic because we know
that it's safe to assume the induction variable won't be changed by the
body of the loop. But why is the induction variable shared in the first
place? If it isn't going to change, it can be private.
+ /* We cannot use the tsubst_omp_clauses since it will try to
+ do checking such as whether a certain clause can be used
+ with a certain for-loop. We are just use schedule clause here
+ as a holder to hold the grain value. */
I don't see the checking you mention. Can't we fix it to do the right
thing?
+ if (code == CILK_FOR)
+ {
+ top_level_body = push_stmt_list ();
+ top_body = begin_omp_parallel ();
+ }
I wouldn't expect the front end to care that Cilk for is implemented
using a parallel call; can't we bring that in at lowering time?
Jason
