[gomp4] Some progress on #pragma omp simd

[Aldy Hernandez]

[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.