Add 'cold' attribute to functions

[Chandler Carruth]

On Wed, May 15, 2013 at 9:31 AM, Diego Novillo <dnovillo at google.com> wrote:

> On 2013-04-10 17:33 , Diego Novillo wrote:
>
>> This patch adds a new function attribute 'cold' to functions.
>>
>
> Thanks for all the feedback.  In fixing up the patch I noticed that there
> is a 'bindings/' directory where attributes seem to play a role.  I'm not
> sure what this is.  Not all the existing attributes seem to exist in these
> bindings.
>

Yea, our bindings are spottily maintained.


>
> Should I add the following changes as well?  There don't seem to be tests
> for these files (nothing I could find in a quick search, anyway).
>

I would add them, but maybe in a separate commit.


> Main patch is attached.  OK to commit?


LGTM. Check w/ Duncan though since he looked at one version of it.

Some comments about the documentation, which don't need to be for this
patch necessarily....

diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index 4d006f1..1c0864d 100644
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -807,6 +807,11 @@ example:
     This attribute indicates that the inliner should attempt to inline
     this function into callers whenever possible, ignoring any active
     inlining size threshold for this caller.
+``cold``
+    This attribute indicates that this function is not called
+    frequently.  When computing edge weights, basic blocks
+    post-dominated by a cold function are also considered to be cold;
+    and, thus, given low weight.

I feel like we should give users a bit more guidance about this attribute,
what semantics we ascribe to it, and under what circumstance it would be
appropriate to use. Specifically, I worry about users thinking they should
use the attribute on a call which happens "only" 30% of the time.

The way I would like to clarify this is to say that the attribute indicates
that the performance of code in that path should be prioritized below any
other performance concerns in the program. Thus, programs should only put
this attribute on code paths which they are fine running with an
arbitrarily large (while bounded) overhead.

I'm not sure what the best way to phrase all of this is though...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130515/e4d20c53/attachment.html>