[LLVMdev] RFC: PerfGuide for frontend authors (original) (raw)

Philip Reames listmail at philipreames.com
Fri Feb 27 21:25:12 PST 2015

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

More information about the llvm-dev mailing list