[LLVMdev] RFC: PerfGuide for frontend authors

[Philip Reames]

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

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