[PATCH] D15245: Use a higher inlining threshold for hot callees.

[Justin Bogner via llvm-commits]

Easwaran Raman <eraman at google.com> writes:
> Justin and Duncan, does this patch look good or do you have any concerns?

It bothers me a bit that this doesn't actually remove the special cases
in profiling code, since they still need to deal with the "cold"
attribute. I kind of feel like there's a more general way to handle all
of this, but I'm okay with this as an incremental step. Thanks!

> On Mon, Dec 7, 2015 at 10:31 AM, Justin Bogner <mail at justinbogner.com> wrote:
>> Easwaran Raman <eraman at google.com> writes:
>>> On Fri, Dec 4, 2015 at 4:13 PM, Justin Bogner <mail at justinbogner.com> wrote:
>>>> Moving this out of the frontend to here makes sense, but I have a couple
>>>> of questions.
>>>>
>>>> - Does this only apply when we've supplied actual profile data, or can
>>>>   we hit it based off of the heuristic counts in no-profile-data mode?
>>>>   If the latter, this isn't quite NFC.
>>>
>>> It applies only when there is profile data since entry count and maximum
>>> function count come only from profile data.
>>>
>>>> - Can the same be done for the "cold" attribute the frontend also
>>>>   applies?
>>>
>>> The difference between the inlinehint and cold attributes is that
>>> the latter is used not just by the inliner. For instance, branch
>>> probability info. I can move it to the backend and replace all calls
>>> to hasFnAttr(Attribute::Cold) with a wrapper that also returns true
>>> if the count is below the threshold. Do you want that change to be
>>> in this patch?
>>
>> That sounds more invasive, so it probably makes sense to consider it
>> separately.