[LLVMdev] RFC: PerfGuide for frontend authors

[David Jones]

I will second point #1 above. It bit me.

May I suggest that for each of these, something is said (ideally an
example) of how to do these things using the API? It's pretty
straightforward when writing IR assembly, but not so obvious when you're
building up the IR using the various calls to methods defined in
include/llvm/IR.

It might also be worthwhile to add information on how to actually invoke
the optimizer and code generator programmatically. My code was based on the
sources for llc in LLVM 3.2, but things have changed since then. If
something as innocuous as forgetting to tweak something in a PassManager
will result in correct, but suboptimal code generation then that's worth
knowing.  (Point #1 is a good example. I had provided a DataLayout to the
TargetMachine at code generation time, but I did not add it to the Module.
Everything ran fine, nothing asserted, but certain obvious optimizations
just did not happen.)


On Fri, Feb 27, 2015 at 6:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150227/9c7ea4ed/attachment.html>