[Balaji, see below]
On 04/23/13 08:54, Jakub Jelinek wrote:
On Mon, Apr 22, 2013 at 05:05:03PM -0500, Aldy Hernandez wrote:
On 04/19/13 08:29, Jakub Jelinek wrote:
If I understood right, vectorlength isn't anything close to it, it is just a
hint, if you vectorize, prefer this vector length, but the compiler is still
responsible for doing the analysis, and punting if it can't prove there is
no aliasing (or go for runtime checks).
Are you sure it's just a hint? (My legalese is very bad). The spec
says "If the vectorlength clause is used, the VL is selected from among
the values of its arguments."
I guess it's not clear what happens if the compiler can't use the
vectorlength argument. Balaji, would this be a hard error? Is this
merely a hint as Jakub says?
So, IMHO you want CILK_SIMD tree (but it can use OMP and CILK clauses etc.),
and GF_OMP_FOR_KIND_CILK_SIMD or so, and perhaps it can be expanded etc.
exactly the same as #pragma omp simd, except for not telling the loop
optimizers that it should imply safelen(+infinity). Or another option
is let the C/C++ FEs, when seeing #pragma omp simd without safelen clause
just add one with some very large value (unsigned TYPE_MAX_VALUE of
a type with precision > precision of the loop iterator?).
Actually, if it's all the same to you, I would prefer the latter. It
seems the easier approach is to have Cilk use OMP_SIMD, and set a
safelen of 0 or something at parse time. Would this be ok, or would you
prefer a separate CILK_SIMD tree which gets expanded into OMP_FOR with a
GF_OMP_FOR_KIND_CILK_SIMD?
BTW, what restrictions has Cilk+ on the for stmt after the pragma?
OpenMP has lots of restrictions, it doesn't allow arbitrary for stmt there.
Like is
int i, j, k;
#pragma simd
for (i = 0, j = 4, k = 5; i < 10 && j < 12; i++, j += 2, k += 3)
...
valid Cilk+? It isn't valid with #pragma omp simd...
You obviously didn't look at the plethora of testcases I included with
my patch :). There are quite a few restrictions, thus the need in my
patch to provide a separate parser for the for loop (not totally unlike
what is done for gomp). See c_check_cilk_loop(), but basically...
1. Initialization is required and can only include one variable.
Variable cannot be volatile, extern, global, register (have any storage
class specifiers).
2. Condition is required and can only be of the form:
DECL <comparison_op> EXPR
EXPR <comparison_op> DECL
Where comparison_op is one of !=, <, <=, >, >=. (== is not allowed).
3. Increment is a simple expression on the induction variable. It is
required, and can only be one of:
++var, var++, --var, var--, var += incr, var -= incr.
Where incr is a conditional-expression with integral (or enum) type.
Can you take a peek at the patch? Are we in agreement wrt the general
approach here-- lest I go too far down the wrong rabbit hole?
Thanks.
