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
This would be great for me. I have had many questions about how optimizable different llvm constructs are. On 02/23/2015 06: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 >-- Rodney Bates rodney.m.bates at acm.org
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> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/6522ab38/attachment.html>
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>
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. 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
----- 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
On 24 Feb 2015, at 00:46, Philip Reames <listmail at philipreames.com> wrote:> > - Use globals not inttoptr for runtime structures - this gives you dereferenceability informationDo we have a mechanism for specifying an address for a global? The places I use inttoptr for runtime structures are all places outside of the JIT environment that I want to specify. Being able to create anonymous globals at a specified address would be very helpful. David
+1 also interested in this answer. -Josh On Sun, Mar 1, 2015 at 5:27 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> On 24 Feb 2015, at 00:46, Philip Reames <listmail at philipreames.com> wrote: > > > > - Use globals not inttoptr for runtime structures - this gives you > dereferenceability information > > Do we have a mechanism for specifying an address for a global? The places > I use inttoptr for runtime structures are all places outside of the JIT > environment that I want to specify. Being able to create anonymous globals > at a specified address would be very helpful. > > David > > > _______________________________________________ > 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/20150301/6f0fe1da/attachment.html>
> On Mar 1, 2015, at 2:27 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 24 Feb 2015, at 00:46, Philip Reames <listmail at philipreames.com> wrote: >> >> - Use globals not inttoptr for runtime structures - this gives you dereferenceability information > > Do we have a mechanism for specifying an address for a global? The places I use inttoptr for runtime structures are all places outside of the JIT environment that I want to specify. Being able to create anonymous globals at a specified address would be very helpful.Not sure. My use cases is using the getSymbolAddress mechanism in MCJIT. Can anyone else comment? Also, we could consider adding a deref(n) metadata to inttoptr or a deref.load metadata to loads to resolve this differently. Either or both are reasonable; I just haven't gotten around to it yet.> > David >
This is great. Can you add it to the release notes? On Fri, Feb 27, 2015 at 3:34 PM, Philip Reames <listmail at philipreames.com> wrote:> 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. > > 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