[LLVMdev] RFC: PerfGuide for frontend authors

Philip Reames listmail at philipreames.com
Wed Feb 25 14:58:33 PST 2015


The review is up: http://reviews.llvm.org/D7890

On 02/25/2015 02:27 PM, Philip Reames wrote:
> 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
>>>
>>>
>>
>
>
>
> _______________________________________________
> 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/20150225/003f99a1/attachment.html>


More information about the llvm-dev mailing list