<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>LLVM patch lgtm.</div><div><br></div><div>Thanks Tyler.<br></div><div><br>On Jul 9, 2014, at 7:40 PM, Tyler Nowicki <<a href="mailto:tnowicki@apple.com">tnowicki@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=windows-1252">If these pragmas are silently ignored when then they don’t have much value. A big part of their value come from the confirmation that they are working. The warning will only be generated on loops with #pragma clang loop vectorize/interleave/unroll specified. It can also be silenced using the command line option -Wno-optimization-warning.<div><br></div><div>I’m still looking into the clang in 32-bit mode question posed earlier. Are there any other comments on the patches?</div><div><br></div><div>Thanks,</div><div><br></div><div>Tyler<br><div><div><br><div><div>On Jul 7, 2014, at 10:45 AM, Mark Heffernan <<a href="mailto:meheff@google.com">meheff@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 3, 2014 at 9:23 AM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This change is raising the severity of this diagnostic. Do we really want to cause build failures in this situation when the code is built with -Werror?<br>
<br>
I think I would be fine with it, if this diagnostic was only triggered when the user specified a #pragma, but if the failure is in the vectorizer, with no hints from the user, then I think a warning is too strong. Even when using #pragma, I'm not sure I'd like a warning here.<br>
</blockquote><div><br></div><div>I'd put my vote in for having a warning if a #pragma optimization directive could not be followed. This assumes the warning is instructive enough that the user can easily fix the issue. I added support for loop unrolling pragmas (following Tyler's vectorization work) so the focus for us is loop unrolling. For the target we care about (CUDA/GPU) a missed loop unroll can be a massive performance loss and the user should know about it. Whatever is decided, I'll make the diagnostic severity of loop unrolling pragma diagnostics match that of the vectorization ones.</div>
<div><br></div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
return false;<br>
}<br>
<br>
@@ -1276,8 +1292,7 @@<br>
emitOptimizationRemarkAnalysis<u></u>(<br>
F->getContext(), DEBUG_TYPE, *F, L->getStartLoc(),<br>
"loop not vectorized due to NoImplicitFloat attribute");<br>
- emitOptimizationRemarkMissed(<u></u>F->getContext(), DEBUG_TYPE, *F,<br>
- L->getStartLoc(), Hints.emitRemark());<br>
+ emitMissedWarning(F, L, Hints);<br>
</blockquote>
<br>
Likewise.<span><font color="#888888"><br>
<br>
<br>
Diego.<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></div></blockquote></body></html>