----- 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
I will second point #1 above. It bit me. May I suggest that for each of these, something is said (ideally an example) of how to do these things using the API? It's pretty straightforward when writing IR assembly, but not so obvious when you're building up the IR using the various calls to methods defined in include/llvm/IR. It might also be worthwhile to add information on how to actually invoke the optimizer and code generator programmatically. My code was based on the sources for llc in LLVM 3.2, but things have changed since then. If something as innocuous as forgetting to tweak something in a PassManager will result in correct, but suboptimal code generation then that's worth knowing. (Point #1 is a good example. I had provided a DataLayout to the TargetMachine at code generation time, but I did not add it to the Module. Everything ran fine, nothing asserted, but certain obvious optimizations just did not happen.) On Fri, Feb 27, 2015 at 6:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- 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 > _______________________________________________ > 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/20150227/9c7ea4ed/attachment.html>
On 02/27/2015 03:58 PM, Hal Finkel wrote:> ----- 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) >Speaking of using TBAA metadata, I notice that LangRef documents the old format, but doesn't explain "struct-path aware TBAA format", making it a challenge to either know how to generate it, or to read metadata that Clang has generated. If someone knowledgeable could update LangRef (in addition to supplying advice for the PerfGuide), it would be appreciated. -Peter-
> On Feb 27, 2015, at 3:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- 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:I'll add these Monday, but am not going to take the time to write much. Any expansion you (or anyone else) want to do would be welcome> > 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 appropriateI was thinking of a more general: use metadata and function attributes. I don't want to end up duplicating content from the Lang ref here. I was thinking that this page should cover the things you can't learn by just reading langref.> > 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 possibleDo you find these help in practice? The few experiments I ran were neutral at best and harmful in one or two cases. Do you have suggestions on how and when to use them? I am using invariant.load, tbaas is constant flag, and a custom hook for zero initialized memory from my allocation routines.> > 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
----- Original Message -----> From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, February 27, 2015 11:25:12 PM > Subject: Re: [LLVMdev] RFC: PerfGuide for frontend authors > > > > On Feb 27, 2015, at 3:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- 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: > I'll add these Monday, but am not going to take the time to write > much. Any expansion you (or anyone else) want to do would be welcomeThanks!> > > > > 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 > I was thinking of a more general: use metadata and function > attributes. > > I don't want to end up duplicating content from the Lang ref here. I > was thinking that this page should cover the things you can't learn > by just reading langref.I agree, I don't want to duplicate the LangRef, but I think that mentioning some of the more-important attributes and metadata for optimization is useful. Unless you read the LangRef quite carefully, and also understand what the optimizer does, it is easy to miss which things are relevant to optimizations. I'd mention them here, and let people look at the LangRef for the definitions.> > > > > 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 > Do you find these help in practice? The few experiments I ran were > neutral at best and harmful in one or two cases. Do you have > suggestions on how and when to use them?Good point, we should be more specific here. My, admittedly limited, experience with these is that they're most useful when their properties are not dynamic -- which perhaps means that they post-dominate the entry, and are applied to allocas in the entry block -- and the larger the objects in question, the more the potential stack-space savings, etc.> > I am using invariant.load, tbaas is constant flag, and a custom hook > for zero initialized memory from my allocation routines.We should discuss this custom hook -- perhaps we'd also benefit from something similar upstream (from calloc, etc.). [Different thread however, I suppose]. -Hal> > > > 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 >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On 02/27/2015 05:06 PM, David Jones wrote:> I will second point #1 above. It bit me. > > May I suggest that for each of these, something is said (ideally an > example) of how to do these things using the API? It's pretty > straightforward when writing IR assembly, but not so obvious when > you're building up the IR using the various calls to methods defined > in include/llvm/IR.As always, patches welcome. :) Though, honestly, I think this is somewhat beyond the scope of the document. I'm expecting the audience for this to be people who already have familiar with the various APIs. This definitely isn't geared towards folks just starting out.> > It might also be worthwhile to add information on how to actually > invoke the optimizer and code generator programmatically. My code was > based on the sources for llc in LLVM 3.2, but things have changed > since then. If something as innocuous as forgetting to tweak something > in a PassManager will result in correct, but suboptimal code > generation then that's worth knowing. (Point #1 is a good example. I > had provided a DataLayout to the TargetMachine at code generation > time, but I did not add it to the Module. Everything ran fine, nothing > asserted, but certain obvious optimizations just did not happen.)While I agree that information on how to invoke the optimizer programmatic belongs somewhere, I'm not sure it needs to be documented, particularly here. This is well covered by the tutorial. Is there something specific you think is missing from there? FYI, I will actively reject patches for things that only effect previous versions. As we move forward, we will branch this doc as part of each release, but that's going to be it. Trying to document every missed optimization that ever existed in LLVM is a inherently futile effort I have no interest in getting into. This is already documented in the commit logs and (possibly) release notes.> > > On Fri, Feb 27, 2015 at 6:58 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > ----- Original Message ----- > > From: "Philip Reames" <listmail at philipreames.com > <mailto:listmail at philipreames.com>> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu > <mailto: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 <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 <mailto: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 > _______________________________________________ > 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/20150302/fb25dce9/attachment.html>
On Fri, Feb 27, 2015 at 9:25 PM, Philip Reames <listmail at philipreames.com> wrote:> > > On Feb 27, 2015, at 3:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- 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: > I'll add these Monday, but am not going to take the time to write much. > Any expansion you (or anyone else) want to do would be welcome > > > > > 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 > I was thinking of a more general: use metadata and function attributes. > > I don't want to end up duplicating content from the Lang ref here. I was > thinking that this page should cover the things you can't learn by just > reading langref. >You can use links to langref if necessary. The audience of this document is people looking for how to generate code that will optimize well. We should bring to their attention any relevant features. LangRef has a very low density for people looking for how to generate code that will optimize well, and I consider it unreasonable to expect them to trawl through it just to pick out a couple small morsels that you are already aware of and can direct them to. Regardless, I think there is more to say about these attributes/metadata than LangRef provides. E.g., LangRef doesn't provide a clear picture of what transformations these things enable, how profitable they can be, and what sort of code they trigger on. For example, a frontend author may be able to get information from their frontend to add noalias, but doing so will require some nontrivial changes to their frontend (and/or slow it down): is it worth it for them to take the time to change their frontend? In order to make this decision, we need to provide them with the information they need to estimate the benefit noalias will bring them. Of course, it's impossible to predict the exact benefit, but we should provide enough information to allow the frontend author to at least prioritize the order in which they investigate using each of these features. -- Sean Silva> > > > > 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 > Do you find these help in practice? The few experiments I ran were > neutral at best and harmful in one or two cases. Do you have suggestions > on how and when to use them? > > I am using invariant.load, tbaas is constant flag, and a custom hook for > zero initialized memory from my allocation routines. > > > > 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 > > _______________________________________________ > 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/20150304/215d3f18/attachment.html>
In the post-commit for r221737, it came to my attention that the assume intrinsic is not to be used indiscriminately. Maybe a section could be added about proper use of assume? The docs in LangRef don't really provide much guidance about when it should be used. -- Sean Silva On Fri, Feb 27, 2015 at 3:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- 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 > _______________________________________________ > 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/20150306/c13c8974/attachment.html>