<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">There was a recent discussion on generating non-temporal stores automatically[1]. This is a hard problem to get right. What seems like a much easier but still useful problem to solve is to provide diagnostics to the user where NT stores *may* help. Then the user can add the corresponding builtins and see if they are beneficial.</div><div class=""><br class=""></div><div class="">My hope is that with the work to add profile-driven optimization diagnostics[2] we could make the number of false positives manageable (eliminate cold loops or hot low-trip count loops, etc.).</div><div class=""><br class=""></div><div class="">On the other hand this requires an interesting new class of optimization remarks. We normally have remarks for optimizations that we automatically perform. Opt remarks report success, failure+reason for automatically performed optimizations. E..g -Rpass-analysis=loop-vectorize will report why loops weren’t vectorized. In this case however we don’t really have a corresponding optimization.</div><div class=""><br class=""></div><div class="">Note that NT stores is just one example here. This is a general problem. We will probably have the same problem when we try to report data-layout transformation opportunities, etc.</div><div class=""><br class=""></div><div class="">I see three ways to solve this:</div><div class=""><br class=""></div><div class="">1. Report it from an existing, similar pass. In this case LoopDataPrefetch may be a candidate. It would still be somewhat strange to ask the user to pass -Rpass-analysis=loop-data-perfetch to see NT store opportunities but may be not too bad.</div><div class=""><br class=""></div><div class="">2. Report it as part of the corresponding analysis. This would probably be LoopAccessAnalysis in this case. We would have to make sure that we only report once even if the analysis is run multiple times. (I am not sure if we had to already solve this for the current set of opt remarks or whether the front-end already has this capability.)</div><div class=""><br class=""></div><div class=""><div class="">3. Add a new (all-analysis-preserving) pass where we emit this and perhaps other remarks like this. It is sort of read-only pass whose sole purpose is to present optimization suggestions to the user.</div><div class=""><br class=""></div><div class="">I think the best is 3 but it could also be considered an overkill at this early stage.</div><div class=""><br class=""></div></div><div class="">We may also want a new subclass for this type of diagnostics. Something like DiagnosticInfoOptimizationRemarkSuggestions, in case we want to filter these differently from Remark/Analysis/Missed.</div><div class=""><br class=""></div><div class="">Please let me know if you have any comments or suggestions.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Adam</div><div class=""><br class=""></div><div class="">[1] <a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98232" class="">http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98232</a></div><div class="">[2] <a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334" class="">http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334</a></div><div class=""><br class=""></div></body></html>