topic I'm still dismayed by the in Software Archive

vectorlengthfor types

Aldy_Hernandez — Fri, 26 Apr 2013 14:54:54 GMT

Hi.

What are the types allowed in the vectorlengthfor clause?

The 1.1 spec just says "type-name" with no restrictions whatsoever. However, the icc 12.1 manual says "data type must be one of built-in integer types (8, 16, 32, or 64bit), pointer types (treated as pointer-sized integer), floating point types (32 or 64bit), or complex types (64bit or 128bit).". Which is correct?

Assuming the icc manual is correct and the spec is lacking, are typedef substitutions allowed? Say, "typedef int typint". Is vectorlength(typint) allowed?

Is someone keeping track of these things? It would be nice if the official specification be corrected (or enhanced).

Thanks,
Aldy

Hi Aldy,

Pablo_H_Intel — Fri, 26 Apr 2013 20:11:10 GMT

Hi Aldy,

The short answer is that the spec is currently correct in that there is no data type restriction on the type in the vectorlengthfor clause. The icc manual implies that there is a restriction because it currently vectorizes on the built-in types. Yes, a typedef is allowed. I do not believe that the specification needs to clarify tha latter point because a typedef is assumed always to be allowed in a linguistic context where they aliased type is allowed.

That said, the long answer is that vectorlengthfor is deprectated. Language discussions have shown it to be of questionable value. This deprecation is one of a handful of issues in the current specification (especially in the vectorization portion of the specification) that we hope to correct soon. Keep asking these questions. The more ambiguities and problems we become aware of, the better our next specification can be.

Regards,

Pablo

I like the long answer better

Aldy_Hernandez — Fri, 26 Apr 2013 20:29:49 GMT

I like the long answer better :), as calculating the vector size this early in the compile pipeline was problematic. I'm glad I don't have to worry about this :).

Thanks.

I'm still dismayed by the

TimP — Sat, 27 Apr 2013 22:02:32 GMT

I'm still dismayed by the inconsistences of the vectorlength directives/pragmas,.

One of our colleagues agreed that some improvement of terminology may be in order. Examples being that CEAN is marketed as part of Cilk+ but as far as I know it's not needed nor permitted to use any vectorlength with CEAN. CEAN just goes ahead and vectorizes, and any vectorlength problem is the programmer's fault. vectorlength also is considered to be a Cilk+ overlay on Fortran, but different numerical arguments are required for identical situations between Fortran and C.

So I guess we can try to learn from scratch with the upcoming 14.0 compilers.

Quote:TimP (Intel) wrote:

Pablo_H_Intel — Mon, 29 Apr 2013 14:46:00 GMT

TimP (Intel) wrote:

I'm still dismayed by the inconsistences of the vectorlength directives/pragmas,.

One of our colleagues agreed that some improvement of terminology may be in order. Examples being that CEAN is marketed as part of Cilk+ but as far as I know it's not needed nor permitted to use any vectorlength with CEAN. CEAN just goes ahead and vectorizes, and any vectorlength problem is the programmer's fault.

CEAN is intended to be a compact and simple notation. Simplicity in this case is inconsistent with too many "knobs and dials." I'm not sure what you mean when you say that "any vectorlength problem is the programmer's fault." What vectorlength problems are you referring to?

TimP (Intel) wrote:

vectorlength also is considered to be a Cilk+ overlay on Fortran, but different numerical arguments are required for identical situations between Fortran and C.

Could you elaborate on that? Again, we are undergoing a significant review of the language specification, so if something needs improvement, now is the time to look at it.

-Pablo