[PATCH] #pragma vectorize

Alexander Musman alexander.musman at gmail.com
Tue Apr 22 10:16:43 PDT 2014


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 <nrotem at apple.com>:

> 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" <tnowicki at apple.com>
> To: cfe-commits at cs.uiuc.edu
> Cc: "Nadav Rotem" <nrotem at apple.com>
> 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
> 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
>
>
>


-- 
Best regards,
Alexander Musman
+79154687051
skype: alexander.musman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140422/676372a4/attachment.html>


More information about the cfe-commits mailing list