[LLVMdev] RFC: PerfGuide for frontend authors

[Sean Silva]

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.

-- Sean Silva

On Fri, Feb 27, 2015 at 3: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/20150306/c13c8974/attachment.html>