[PATCH] D25467: [ELF] - Alternative fix to prevent possible crash on large output.
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 17 15:21:12 PDT 2016
On Mon, Oct 17, 2016 at 3:06 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Mon, Oct 17, 2016 at 2:26 PM, Rui Ueyama via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > This is a list of items that popped in my mind. Not exhaustive but
> > good enough to start discussing what we should do next.
> > - FreeBSD: what is the status of building the entire FreeBSD system with
> > LLD? Can it build everything including the kernel?
> Another idea, which I discussed with Rafael and Michael a bit ago.
> Implement support for order file. For starters, you don't need anything
> Just get a list of symbols (which can be generated by systap or a
> profiler) and pass that to the linker, so that sections are laid out
> according to the partial order defined in the file (you can always
> reconstruct a total order starting from a partial order using some
> heuristic). This is particularly useful to improve startup time as you
> reduce the amount of paging. Firefox uses this for sure, and
> apparently ld64 implements this algorithm (or a slight variation of
> it). I'm confident this is quite effective (see Martin Liska's thesis
> which contains a more detailed description of the problem and
> references https://arxiv.org/pdf/1403.6997.pdf)
That's an effective technique for spinning disks for sure, but how about on
Once this is done, and we convince ourselves is a good thing, we can
> try implementing Pettis-Hansen ordering (guided by profiling
> informations) as Srinaman did for gold.
> That should help putting code accessed frequently together near to
> reduce I-cache traffic etc..
> I'm not sure if it's actually effective (I hope so), maybe
> Srinaman/David have more informations about it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits