----- Original Message ----- > From: "Tyler Nowicki" <[email protected]> > To: "Hal Finkel" <[email protected]> > Cc: "Nadav Rotem" <[email protected]>, "Alexey Bataev" > <[email protected]>, "llvm cfe" <[email protected]> > 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 < [email protected] > wrote: > > > > ----- Original Message ----- > > > From: "Nadav Rotem" < [email protected] > > To: "Raul Silvera" < [email protected] > > Cc: "Hal Finkel" < [email protected] >, "Alexey Bataev" < > [email protected] >, "llvm cfe" < [email protected] > > Sent: Tuesday, April 22, 2014 1:30:39 PM > Subject: Re: [PATCH] #pragma vectorize > > > > > On Apr 22, 2014, at 11:24 AM, Raul Silvera < [email protected] > > 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 | [email protected] | 408-789-2846 > > > > On Tue, Apr 22, 2014 at 10:49 AM, Hal Finkel < [email protected] > > wrote: > > > > ----- Original Message ----- > > > From: "Nadav Rotem" < [email protected] > > To: "Hal Finkel" < [email protected] > > > > > Cc: "Tyler Nowicki" < [email protected] >, [email protected] > , "Alexey Bataev" < [email protected] >, > "Alexander Musman" < [email protected] >, "Chandler > Carruth" < [email protected] > > > > > Sent: Tuesday, April 22, 2014 12:44:21 PM > Subject: Re: [PATCH] #pragma vectorize > > > > > > > > On Apr 22, 2014, at 10:38 AM, Hal Finkel < [email protected] > 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
