<div dir="ltr"><div>In the post-commit for r221737, it came to my attention that the assume intrinsic is not to be used indiscriminately. Maybe a section could be added about proper use of assume? The docs in LangRef don't really provide much guidance about when it should be used.<br><br></div>-- Sean Silva<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 3:58 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Philip Reames" <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>><br>
> To: "LLVM Developers Mailing List" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
> Sent: Friday, February 27, 2015 5:34:36 PM<br>
> Subject: Re: [LLVMdev] RFC: PerfGuide for frontend authors<br>
><br>
> The first version of this document is now live:<br>
> <a href="http://llvm.org/docs/Frontend/PerformanceTips.html" target="_blank">http://llvm.org/docs/Frontend/PerformanceTips.html</a><br>
><br>
> Please feel free to add to it directly. Alternatively, feel free to<br>
> reply to this thread with text describing an issue that should be<br>
> documented. I'll make sure text gets turned into patches.<br>
<br>
</span>First, thanks for working on this! Some things (perhaps) worth mentioning:<br>
<br>
1. Make sure that a DataLayout is provided (this will likely become required in the near future, but is certainly important for optimization).<br>
<br>
2. Add nsw/nuw/fast-math flags as appropriate<br>
<br>
3. Add noalias/align/dereferenceable/nonnull to function arguments and return values as appropriate<br>
<br>
4. Mark functions as readnone/readonly/nounwind when known (especially for external functions)<br>
<br>
5. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing analysis), prefer GEPs<br>
<br>
6. Use the lifetime.start/lifetime.end and invariant.start/invariant.end intrinsics where possible<br>
<br>
7. Use pointer aliasing metadata, especially tbaa metadata, to communicate otherwise-non-deducible pointer aliasing facts<br>
<br>
8. Use the "most-private" possible linkage types for the functions being defined (private, internal or linkonce_odr preferably)<br>
<br>
-Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Philip<br>
><br>
> On 02/23/2015 04:46 PM, Philip Reames wrote:<br>
> > I'd like to propose that we create a new Performance Guide<br>
> > document.<br>
> > The target of this document will be frontend authors, not<br>
> > necessarily<br>
> > LLVM contributors. The content will be a collection of items a<br>
> > frontend author might want to know about how to generate LLVM IR<br>
> > which<br>
> > will optimize well.<br>
> ><br>
> > Some ideas on topics that might be worthwhile:<br>
> > - Prefer sext over zext when value is known to be positive in the<br>
> > language (e.g. range checked index on a GEP)<br>
> > - Avoid loading and storing first class aggregates (i.e. they're<br>
> > not<br>
> > well supported in the optimizer)<br>
> > - Mark invariant locations - i.e. link to !invariant.load and TBAA<br>
> > constant flags<br>
> > - Use globals not inttoptr for runtime structures - this gives you<br>
> > dereferenceability information<br>
> > - Use function attributes where possible (nonnull, deref, etc..)<br>
> > - Be ware of ordered and atomic memory operations (not well<br>
> > optimized), depending on source language, might be faster to use<br>
> > fences.<br>
> > - Range checks - make sure you test with the IRCE pass<br>
> ><br>
> > If folks are happy with the idea of having such a document, I<br>
> > volunteer to create version 0.1 with one or two items. After that,<br>
> > we<br>
> > can add to it as folks encounter ideas. The initial content will<br>
> > be<br>
> > fairly minimal, I just want a link I can send to folks in reviews<br>
> > to<br>
> > record comments made. :)<br>
> ><br>
> > Philip<br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>