[cfe-dev] Why doesn't pragma vectorize warn by default on failure

[Gonzalo BG via cfe-dev]

Back to this topic, I still have two issues.

First consider a "for_each" like function (this is a minimal example):

 template <typename F>  //
 [[gnu::flatten]] constexpr auto for_each(int length, F&& f) noexcept {
      #pragma clang loop vectorize(enable) interleave(enable)
      for (int i = 0; i < length; ++i)  f(i);
 }

This function will be typically inlined at every point of usage. Depending
on the values of length, min, max, the function might be vectorized or not.

However, -Rpass-analysis=loop-vectorize only tells if the loop of the
function was vectorized, and points to the loop. In a large program, one
will get that the loop is sometimes vectorized and sometimes isn't. There
is no way to traceback in which context this happened. Without this
information, there is not much one can do about it. Does it make sense that
the function is/isn't vectorized? It is impossible to know, and it is
impossible to "repair" those places in which vectorization failed.

The second issue is that of alignment and restrict. I would like the
Rpass-analysis=loop-vectorize flag to tell me when marking one pointer with
restrict or when providing the alignment of one pointer or variable would
enable vectorization, or even better, if it would tell me when it would
enable better code generation (like generating code for a single vectorized
version of the loop instead of checking all possible combinations of
alignment, aliasing,... at run-time and trashing the instruction cache).

On Thu, Jul 23, 2015 at 8:55 PM, Tyler Nowicki <tnowicki at apple.com> wrote:

> I would also like to get a full diagnostic about why vectorization failed.
> That is, have -Rpass-missed=loop-vectorize and
> -Rpass-analysis=loop-vectorize enabled by default.
>
>
> That’s a good idea, I think it would solve the problem you are seeing. We
> should enable the remarks for code with a pragma hint. Thinking about the
> implementation, I can’t say off the top of my head how to pass that
> information to the BackendConsumer where remarks are emitted. If I get time
> I’ll do this, but I’m pretty swamped right now.
>
>
> > Its possible there is a bug in the code for generating the warning or we
> missed generating it somewhere. Could you provide the loop body?
>
> I provide a minimal example below (in Appendix A). It seems the diagnostic
> triggers or not depending on the optimization level selected, which makes
> sense now that I looked more into it. For example:
>
> When compiling with O0, O2, O3, and Ofast I get no diagnostic, and in
> fact, the loop is not vectorized because it is actually eliminated.
> When compiling with O1 I get by default without passing any extra flags
> the diagnostic I wanted:
>
> > file.cpp:13:1: error: loop not vectorized: failed explicitly specified
> loop
> >      vectorization [-Werror,-Wpass-failed]
> >}
> >^
> >
> >1 error generated.
>
> It is also not hard to get "no diagnostic" even for loops that could be
> vectorized (godbolt+assembly: http://goo.gl/nfeXOX). In that example, the
> code is vectorized for a size of 100. But changing the size of 8 removes
> the vectorization "silently". This is good and makes sense. For a size of 8
> it is probably not worth it to vectorize the loop, and whatever cost model
> the vectorizer uses knows this.
>
>
> Its an interesting example. When SIZE=8 the loop unroller removes the
> loop. Actually the vectorizer doesn’t even see it! That makes it difficult
> to generate a diagnostic in the loop vectorizer. And there are many passes
> that can remove a loop entirely before it gets to the vectorizer causing
> the “no diagnostic” problem. Some of these passes generate a remark. For
> example: -Rpass=unroll says the loop in your example was “completely
> unrolled loop with 8 iterations”. We should extend the diagnostics to all
> passes that could remove a loop, such as the LoopDelete pass. In
> combination with your suggestion above that should resolve the “no
> diagnostics” problem.
>
> Thanks for taking the time to generate the example and think about a
> solution. It's a lot of help!
>
> Tyler
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160223/5c3aa193/attachment.html>