<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/27/2015 05:06 PM, David Jones
wrote:<br>
</div>
<blockquote
cite="mid:CAEwg-QKQRs3iPa=oU+idyhk3Ar+gpaaGMK2njOxdPr2VjiCFHQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>I will second point #1 above. It bit me.<br>
<br>
</div>
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.<br>
</div>
</div>
</blockquote>
As always, patches welcome. :)<br>
<br>
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.<br>
<blockquote
cite="mid:CAEwg-QKQRs3iPa=oU+idyhk3Ar+gpaaGMK2njOxdPr2VjiCFHQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
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.)<br>
</div>
</blockquote>
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?<br>
<br>
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.<br>
<blockquote
cite="mid:CAEwg-QKQRs3iPa=oU+idyhk3Ar+gpaaGMK2njOxdPr2VjiCFHQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Feb 27, 2015 at 6:58 PM, Hal
Finkel <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">----- Original Message -----<br>
> From: "Philip Reames" <<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>><br>
> To: "LLVM Developers Mailing List" <<a
moz-do-not-send="true" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
> Sent: Friday, February 27, 2015 5:34:36 PM<br>
> Subject: Re: [LLVMdev] RFC: PerfGuide for frontend
authors<br>
><br>
> The first version of this document is now live:<br>
> <a moz-do-not-send="true"
href="http://llvm.org/docs/Frontend/PerformanceTips.html"
target="_blank">http://llvm.org/docs/Frontend/PerformanceTips.html</a><br>
><br>
> Please feel free to add to it directly.
Alternatively, feel free to<br>
> reply to this thread with text describing an issue
that should be<br>
> documented. I'll make sure text gets turned into
patches.<br>
<br>
</span>First, thanks for working on this! Some things
(perhaps) worth mentioning:<br>
<br>
1. Make sure that a DataLayout is provided (this will
likely become required in the near future, but is certainly
important for optimization).<br>
<br>
2. Add nsw/nuw/fast-math flags as appropriate<br>
<br>
3. Add noalias/align/dereferenceable/nonnull to function
arguments and return values as appropriate<br>
<br>
4. Mark functions as readnone/readonly/nounwind when known
(especially for external functions)<br>
<br>
5. Use ptrtoint/inttoptr sparingly (they interfere with
pointer aliasing analysis), prefer GEPs<br>
<br>
6. Use the lifetime.start/lifetime.end and
invariant.start/invariant.end intrinsics where possible<br>
<br>
7. Use pointer aliasing metadata, especially tbaa metadata,
to communicate otherwise-non-deducible pointer aliasing
facts<br>
<br>
8. Use the "most-private" possible linkage types for the
functions being defined (private, internal or linkonce_odr
preferably)<br>
<br>
-Hal<br>
<div class="HOEnZb">
<div class="h5"><br>
><br>
> Philip<br>
><br>
> On 02/23/2015 04:46 PM, Philip Reames wrote:<br>
> > I'd like to propose that we create a new
Performance Guide<br>
> > document.<br>
> > The target of this document will be frontend
authors, not<br>
> > necessarily<br>
> > LLVM contributors. The content will be a
collection of items a<br>
> > frontend author might want to know about how
to generate LLVM IR<br>
> > which<br>
> > will optimize well.<br>
> ><br>
> > Some ideas on topics that might be worthwhile:<br>
> > - Prefer sext over zext when value is known to
be positive in the<br>
> > language (e.g. range checked index on a GEP)<br>
> > - Avoid loading and storing first class
aggregates (i.e. they're<br>
> > not<br>
> > well supported in the optimizer)<br>
> > - Mark invariant locations - i.e. link to
!invariant.load and TBAA<br>
> > constant flags<br>
> > - Use globals not inttoptr for runtime
structures - this gives you<br>
> > dereferenceability information<br>
> > - Use function attributes where possible
(nonnull, deref, etc..)<br>
> > - Be ware of ordered and atomic memory
operations (not well<br>
> > optimized), depending on source language,
might be faster to use<br>
> > fences.<br>
> > - Range checks - make sure you test with the
IRCE pass<br>
> ><br>
> > If folks are happy with the idea of having
such a document, I<br>
> > volunteer to create version 0.1 with one or
two items. After that,<br>
> > we<br>
> > can add to it as folks encounter ideas. The
initial content will<br>
> > be<br>
> > fairly minimal, I just want a link I can send
to folks in reviews<br>
> > to<br>
> > record comments made. :)<br>
> ><br>
> > Philip<br>
> >
_______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> > <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span>
<div class="HOEnZb">
<div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>