[PATCH] D48808: [CodeGen] Emit parallel_loop_access for each loop in the loop stack.

Tyler Nowicki via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 2 10:27:28 PDT 2018


Hi Michael, Hal,

Sorry it has been a while since I looked at this. My memory is a little
fuzzy. The intent of 'assume_safety' is to tell LAA to skip dependency
checking on loads and stores so the vectorizer doesn't stop as soon as it
sees both in a loop. At the time 'assume_safety' was implemented the
vectorizer was limited to inner-loops. I am not up-to-date but it seems to
have the ability to perform some vectorization of non-inner loop
instructions?

If we can vectorize non-inner loop instructions then what behavior would
make the most sense: 'assume_safety' applies to the same loop scope(s) as
the other loop pragmas, or it applies to all nested loops?

My opinion is that for consistency 'assume_safety' and similar options
apply to the same scope(s) as 'vectorize(enable)'. But I am open to
alternatives if others see it differently.

Tyler Nowicki

On Mon, Jul 2, 2018 at 10:44 AM Michael Kruse via Phabricator <
reviews at reviews.llvm.org> wrote:

> Meinersbur added a comment.
>
> In https://reviews.llvm.org/D48808#1149534, @ABataev wrote:
>
> > I don't think that this is the intended behavior of the `#pragma clang
> loop`. it is better to ask the author of this pragma is this correct or not.
>
>
> I understand it as the intended behavior of the `assume_safety` option
> (also used for `#pragma omp simd`).
>
> @tyler.nowicki What is the intended behaviour?
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D48808
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180702/61a59761/attachment.html>


More information about the cfe-commits mailing list