<div dir="ltr">Back to this topic, I still have two issues.<br><br>First consider a "for_each" like function (this is a minimal example):  <br><br><div> template <typename F>  //</div><div> [[gnu::flatten]] constexpr auto for_each(int length, F&& f) noexcept {</div><div>      #pragma clang loop vectorize(enable) interleave(enable)</div><div>      for (int i = 0; i < length; ++i)  f(i);</div><div> }<br><br>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. <br><br>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.<br><br>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).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 23, 2015 at 8:55 PM, Tyler Nowicki <span dir="ltr"><<a href="mailto:tnowicki@apple.com" target="_blank">tnowicki@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div dir="ltr">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.</div></blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><span style="font-size:12.8000001907349px">> 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?<br></span><br>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:<br><br>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.<br>When compiling with O1 I get by default without passing any extra flags the diagnostic I wanted: <br><br>> file.cpp:13:1: error: loop not vectorized: failed explicitly specified loop<br>>      vectorization [-Werror,-Wpass-failed]<br>>}<br>>^<br>><br>>1 error generated.<br><br>It is also not hard to get "no diagnostic" even for loops that could be vectorized (godbolt+assembly: <a href="http://goo.gl/nfeXOX" target="_blank">http://goo.gl/nfeXOX</a>). 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. <br></div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>Thanks for taking the time to generate the example and think about a solution. It's a lot of help!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Tyler</div></font></span></div><br></div></blockquote></div><br></div>