[PATCH] #pragma vectorize

[Hal Finkel]

----- Original Message -----
> From: "Tyler Nowicki" <tnowicki at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Nadav Rotem" <nrotem at apple.com>, "Alexey Bataev" <alexey.bataev at intel.com>, "llvm cfe" <cfe-commits at cs.uiuc.edu>
> Sent: Tuesday, April 22, 2014 2:01:53 PM
> Subject: Re: [PATCH] #pragma vectorize
> 
> 
> 
> Ok, so trying to recap the consensus seems to be for the following
> syntax
> 
> 
> #pragma interleave(_value_)

This can be enabled/disabled separately. Currently:
  - enable -> do nothing
  - disable -> set the vector unroll metadata to 1
so, while technically not needed, I think that we should accept enable and disable here as well.

> - indicates the loop body should be unrolled

Yes, although we should be specific, obviously, in the documentation that this means interleaved unrolling, and that means that the different loop iterations are unsequenced with respect to each other.

> - does not imply that it is safe to do so

Hrmm; interesting. Is this the behavior we want? I'd be inclined to say that the pragma should imply safety.

Thanks again,
Hal

> 
> 
> #pragma vectorize width(_value_)/enable/disable
> - behavior remains the same
> 
> 
> And rename `class LoopVectorizeHints' to `class LoopHints'.
> 
> 
> Is that right? Did I miss anything?
> 
> 
> Tyler
> 
> 
> On Apr 22, 2014, at 11:39 AM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> 
> ----- Original Message -----
> 
> 
> From: "Nadav Rotem" < nrotem at apple.com >
> To: "Raul Silvera" < rsilvera at google.com >
> Cc: "Hal Finkel" < hfinkel at anl.gov >, "Alexey Bataev" <
> alexey.bataev at intel.com >, "llvm cfe" < cfe-commits at cs.uiuc.edu >
> Sent: Tuesday, April 22, 2014 1:30:39 PM
> Subject: Re: [PATCH] #pragma vectorize
> 
> 
> 
> 
> On Apr 22, 2014, at 11:24 AM, Raul Silvera < rsilvera at google.com >
> wrote:
> 
> 
> 
> 
> Does this pragma widen also asserts safety, or does it depend on the
> compiler proving independence?
> 
> 
> This specific pragma only affects the decision of the vectorizer
> 'cost model'.
> 
> 
> 
> 
> 
> 
> widen does seem to imply the data types are being widened -- also a
> form of vectorization. Perhaps interleave is another word to
> consider?
> 
> 
> I also like ‘interleave’.
> 
> 
> I like this as well.
> 
> -Hal
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Raúl E Silvera | SWE | rsilvera at google.com | 408-789-2846
> 
> 
> 
> On Tue, Apr 22, 2014 at 10:49 AM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> ----- Original Message -----
> 
> 
> From: "Nadav Rotem" < nrotem at apple.com >
> To: "Hal Finkel" < hfinkel at anl.gov >
> 
> 
> 
> Cc: "Tyler Nowicki" < tnowicki at apple.com >, cfe-commits at cs.uiuc.edu
> , "Alexey Bataev" < alexey.bataev at intel.com >,
> "Alexander Musman" < alexander.musman at gmail.com >, "Chandler
> Carruth" < chandlerc at google.com >
> 
> 
> 
> Sent: Tuesday, April 22, 2014 12:44:21 PM
> Subject: Re: [PATCH] #pragma vectorize
> 
> 
> 
> 
> 
> 
> 
> On Apr 22, 2014, at 10:38 AM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> Okay, this is reasonable, but I'm still not sure it should be in a
> pragma called 'vectorize'. This particular transformation can be
> applied (and more often than not is applied) to scalar code.
> Strictly speaking it is an optimization that exposes ILP, and has
> little to do with vectorization.
> 
> 
> This is a good point. Maybe ILP would be a better name?
> 
> No, actually I like widen better because it is an action word. I
> don't think that ILP gives any idea of what the compiler is being
> asked to do. Not that I'm in love with widen, but I don't have a
> better suggestion -- unsequenced_unrolling or
> unsequenced_iterations, etc. all seem a bit bulky ;)
> 
> -Hal
> 
> 
> 
> 
> 
> 
> 
> 
> 
> That having been said, the fact that the correctness model for this
> 'widening' operation is similar (although not identical) to that
> for
> vectorization, and thus implemented by the vectorizer, is not facet
> of the implementation we should expose to the user. However, pragma
> widen is fine with me too.
> 
> 
> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 
> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory