[llvm-dev] [RFC] Profile guided section layout

[Davide Italiano via llvm-dev]

I'm definitely interested in seeing this moving forward, (phabricator
will make the review easy), quick question, why the option is phrased
as negative? (i.e. --disable instead of --enable?)

Thanks,

--
Davide

On Mon, Jul 31, 2017 at 3:12 PM, Rafael Espíndola via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> A rebased version of the lld patch is attached.
>
> Cheers,
> Rafael
>
>
> On 31 July 2017 at 15:11, Rafael Avila de Espindola
> <rafael.espindola at gmail.com> wrote:
>> Tobias Edler von Koch <tobias at codeaurora.org> writes:
>>
>>> Hi Rafael,
>>>
>>> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote:
>>>> However, do we need to start with instrumentation? The original paper
>>>> uses sampling with good results and current intel cpus can record every
>>>> branch in a program.
>>>>
>>>> I would propose starting with just an lld patch that reads the call
>>>> graph from a file. The format would be very similar to what you propose,
>>>> just weight,caller,callee.
>>>
>>> The advantage of the proposed approach (weighted callgraph section) is
>>> that it's completely transparent: it works regardless of the particular
>>> profiling methodology (as long as there's !perf metadata when the pass
>>> runs). For this reason, it fits neatly into an *existing* PGO-based
>>> build flow. I only need to add 1 compiler flag to enable it. That's a
>>> big plus.
>>>
>>> On the other hand, I could see how your idea (callgraph input file for
>>> linker) would be useful in situations where I just want to do section
>>> layout but no PGO in the compiler... and of course for testing of the
>>> linker's sorting algorithm.
>>>
>>> So there's merits in both, but for my use cases Michael's original
>>> approach is the most practical.
>>
>> Yes, I must stress that I am not proposing having the option of reading
>> the callgraph from another file *instead* of reading it from .o
>> files. Just that doing it first decouples most of the lld patch form the
>> llvm changes and can be useful in cases where only samples are available.
>>
>> Cheers,
>> Rafael
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare