<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/04/2015 07:50 PM, Sean Silva
wrote:<br>
</div>
<blockquote
cite="mid:CAHnXoamUewi5pX1mdOgPZJAkj3ijMFh0CtrPfGeehOxLkf_mNA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Feb 27, 2015 at 9:25 PM,
Philip Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
> On Feb 27, 2015, at 3:58 PM, Hal Finkel <<a
moz-do-not-send="true" href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>
wrote:<br>
><br>
> ----- 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>
> First, thanks for working on this! Some things
(perhaps) worth mentioning:<br>
</span>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<br>
<span class=""><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>
</span>I was thinking of a more general: use metadata and
function attributes.<br>
<br>
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.<br>
</blockquote>
<div><br>
</div>
<div>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.<br>
<br>
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.<br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAHnXoamUewi5pX1mdOgPZJAkj3ijMFh0CtrPfGeehOxLkf_mNA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
My initial sketch would be:<br>
Use metadata/attributes!<br>
- topic - dereferenceability (i.e. deref, deref_or_null,
deref.load!) (The last two don't exist yet!)<br>
- topic - aliasing properties (noalias, etc..)<br>
- subtopic - invariant <br>
- subtopic - tbaa<br>
- topic - value properties (range, non-null)<br>
<br>
The focus would be on linking to right sections in LangRef and
discussing profitability. I don't want to duplicate syntax or API
docs. <br>
<br>
<br>
<blockquote
cite="mid:CAHnXoamUewi5pX1mdOgPZJAkj3ijMFh0CtrPfGeehOxLkf_mNA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>-- Sean Silva<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><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>
</span>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?<br>
<br>
I am using invariant.load, tbaas is constant flag, and a
custom hook for zero initialized memory from my allocation
routines.<br>
<div class="HOEnZb">
<div class="h5">><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>
><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>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>