[LLVMdev] RFC: PerfGuide for frontend authors

[Philip Reames]

I'm moving forward with this now given no one has raised objections.

Based on Sean's comments, the naming I'm going to use is: 
FrontendInfo/PerfTips

I plan on committing an initial version based on what was discussed here 
without further review.  I'm going to keep the first version short, and 
then open it for others to contribute.

Philip

On 02/24/2015 02:13 PM, Sean Silva wrote:
> SGTM.
>
> I like your idea of starting "perf tips" as sort of isolated 
> guidelines for better IRGen. Should allow some nice incremental growth 
> of the documentation. I expect some stuff will need a bit more 
> discussion, so I would like this document to be in a directory 
> docs/FrontendInfo/ or something like that (bikeshed) so that we can 
> easily split out into new docs as needed for some breathing room, or 
> to give some structure for readers to follow.
>
> Our optimizer and backends are our lifeblood, but frontends are our 
> reason for existence. This kind of frontend-oriented documentation has 
> been needed for a long time. Thanks for kicking it off!
>
> -- Sean Silva
>
> On Mon, Feb 23, 2015 at 4:46 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> 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 <mailto: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/20150225/039728fb/attachment.html>