[LLVMdev] RFC: PerfGuide for frontend authors

[Philip Reames]

On further thought, I don't think the extra directory structure is 
warranted yet.  We have several other frontend relevant docs at the top 
level so splitting off a directory without moving them would just make 
things more confusing.

Given that, tentative name is docs/PerfTips.rst and this will be going 
out as a code review to give time for others to comment on naming.

Philip

On 02/25/2015 02:22 PM, Philip Reames wrote:
> 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/6002c170/attachment.html>