[LLVMdev] RFC: PerfGuide for frontend authors

Philip Reames listmail at philipreames.com
Wed Mar 4 23:37:21 PST 2015 

On 03/04/2015 07:50 PM, Sean Silva wrote:
>
>
> On Fri, Feb 27, 2015 at 9:25 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>
>     > On Feb 27, 2015, at 3: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:
>     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.
I'm going to take a shot at such a section eventually, but it's my 
lowest priority item on this documentation.  If you want to propose a 
patch, please feel free.

My initial sketch would be:
Use metadata/attributes!
- topic - dereferenceability (i.e. deref, deref_or_null, deref.load!) 
(The last two don't exist yet!)
- topic - aliasing properties (noalias, etc..)
   - subtopic - invariant
   - subtopic - tbaa
- topic - value properties (range, non-null)

The focus would be on linking to right sections in LangRef and 
discussing profitability.  I don't want to duplicate syntax or API docs.


>
> -- 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 <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/20150304/ccf90155/attachment.html>

More information about the llvm-dev mailing list