[LLVMdev] RFC: PerfGuide for frontend authors

[Hal Finkel]

----- Original Message -----
> From: "Philip Reames" <listmail at philipreames.com>
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Friday, February 27, 2015 5:34:36 PM
> Subject: Re: [LLVMdev] RFC: PerfGuide for frontend authors
> 
> The first version of this document is now live:
> http://llvm.org/docs/Frontend/PerformanceTips.html
> 
> Please feel free to add to it directly.  Alternatively, feel free to
> reply to this thread with text describing an issue that should be
> documented.  I'll make sure text gets turned into patches.

First, thanks for working on this! Some things (perhaps) worth mentioning:

 1. Make sure that a DataLayout is provided (this will likely become required in the near future, but is certainly important for optimization).

 2. Add nsw/nuw/fast-math flags as appropriate

 3. Add noalias/align/dereferenceable/nonnull to function arguments and return values as appropriate

 4. Mark functions as readnone/readonly/nounwind when known (especially for external functions)

 5. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing analysis), prefer GEPs

 6. Use the lifetime.start/lifetime.end and invariant.start/invariant.end intrinsics where possible

 7. Use pointer aliasing metadata, especially tbaa metadata, to communicate otherwise-non-deducible pointer aliasing facts

 8. Use the "most-private" possible linkage types for the functions being defined (private, internal or linkonce_odr preferably)

 -Hal

> 
> Philip
> 
> On 02/23/2015 04:46 PM, Philip Reames wrote:
> > I'd like to propose that we create a new Performance Guide
> > document.
> > The target of this document will be frontend authors, not
> > necessarily
> > LLVM contributors.  The content will be a collection of items a
> > frontend author might want to know about how to generate LLVM IR
> > which
> > will optimize well.
> >
> > Some ideas on topics that might be worthwhile:
> > - Prefer sext over zext when value is known to be positive in the
> > language (e.g. range checked index on a GEP)
> > - Avoid loading and storing first class aggregates (i.e. they're
> > not
> > well supported in the optimizer)
> > - Mark invariant locations - i.e. link to !invariant.load and TBAA
> > constant flags
> > - Use globals not inttoptr for runtime structures - this gives you
> > dereferenceability information
> > - Use function attributes where possible (nonnull, deref, etc..)
> > - Be ware of ordered and atomic memory operations (not well
> > optimized), depending on source language, might be faster to use
> > fences.
> > - Range checks - make sure you test with the IRCE pass
> >
> > If folks are happy with the idea of having such a document, I
> > volunteer to create version 0.1 with one or two items.  After that,
> > we
> > can add to it as folks encounter ideas.  The initial content will
> > be
> > fairly minimal, I just want a link I can send to folks in reviews
> > to
> > record comments made.  :)
> >
> > Philip
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory