Hi All, One particularly interesting case would be to allow user specify the maximum vector length - such number of iterations that user knows there is no loop-carried dependence with less than that number - and then let vectorizer choose any width/unroll combination based on its heuristics and target information.
omp simd's 'safelen' clause would specify such number, and probably it would be useful to have such ability with #pragma vectorize as well. In our github implementation we currently only set 'width' to the 'safelen' value. 2014-04-22 20:34 GMT+04:00 Nadav Rotem <[email protected]>: > Hi Hal, > > Thanks for the review and for your support of this feature. > > I feel strongly that we should separate the unrolling pragma from the > vectorization pragma. The fact that modulo unrolling is implemented by our > loop vectorizer is an implementation detail that I do not want to expose to > our users directly. > > > I think that the name ‘unroll’ is misleading because what the vectorizer > does is not the usual loop unrolling. The vectorizer uses two or more SIMD > registers to perform the widened scalar operations. I would like to allow > users to control this special kind of unrolling within the vectorization > pragma. Maybe we should give it a different name, like ‘widen’ ? > > Also, we have a concatenation unroller which performs unrolling separate > from the vectorizer. I think we should do something like this: > > 1. For the purpose of this patch, please split off the unrolling into a > separate pragma: > #pragma unroll(_value_ | enable | disable) > > 2. In the future, this syntax will be enhanced to something like this: > #pragma unroll(unroll-spec-list) > > unroll-spec-list: > kind_prefix_opt unroll-spec > > unroll-spec: > _value_ > enable > disable > > kind_prefix: > kind : > > kind: > sequenced : > unsequenced : > any : > > [this sequenced vs unsequenced terminology is what we decided we liked for > the parallel algorithms library being considered in WG21, and I think it > applies just as well here] > > In our implementation, 'unsequenced' unrolling means the modulo unrolling > performed by the loop vectorizer. 'sequenced' unrolling means the > concatenation unrolling performed by the generic unroller. > > Adding Chandler, he might have some opinion on my use of the sequenced vs. > unsequenced suggestion. > > Also, adding Alexey and Alexander who have done some similar work in > clang-omp. > > -Hal > > ----- Original Message ----- > > From: "Tyler Nowicki" <[email protected]> > To: [email protected] > Cc: "Nadav Rotem" <[email protected]> > Sent: Monday, April 21, 2014 6:23:02 PM > Subject: [PATCH] #pragma vectorize > > > > Hi, > > Please review the attached patch for adding pragma vectorize syntax / > vectorization hints to clang. > > pragma vectorize > * supports the options enable, disable, unroll(_value_), and > width(_value_) > * options are turned into vectorization hints that are used during > codegen to add metadata to the conditional branch of the for, while, > and do-while loops. > * enable forces the vectorizer to consider the loop, for example when > compiling with Os > * disable prevents vectorization of the loop > * The _value_ specified by unroll(_value_) and width(_value_) must be > a positive integer. It will be used to set the > llvm.vectorizer.unroll or llvm.vectorizer.width metadata values. > > Thank you, > > Tyler Nowicki > Apple > > > > _______________________________________________ > 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 > > > -- Best regards, Alexander Musman +79154687051 skype: alexander.musman
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
