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>
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>
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>