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

[Michael Spencer via llvm-dev]

On Mon, Jul 31, 2017 at 5:26 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> I updated the patch to read a call graph from a text file.
>
> I tested it with the attached call.txt from lld linking chromium.
> Unfortunately the resulting lld doesn't seem any faster. One thing I
> noticed is that the most used symbols seem to be at the end of the
> file.
>

Not all programs will get faster as it really depends on the working set
size of the code. While lld is kinda large, if you're not running LTO then
the instruction working set is pretty small.


> In any case, can you add tests and send the lld patch for review?
>

Yep, should have that tomorrow.

- Michael Spencer


>
> Thanks,
> Rafael
>
>
>
> On 31 July 2017 at 15:19, Davide Italiano <davide at freebsd.org> wrote:
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170731/a3e7693a/attachment.html>