[LLVMdev] RFC: PerfGuide for frontend authors

Peter S. Housel housel at acm.org
Fri Feb 27 17:59:34 PST 2015


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-




More information about the llvm-dev mailing list