[patch][rfc] Implicit sections

[Eric Christopher]

Looks fine to me. There are some concerns with a linker that does this and
things that require mucking about with them, but this patch is just fine as
other linkers aren't going to be affected anyhow :)

-eric

On Thu Feb 12 2015 at 12:37:57 PM Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> Updated patch using TargetOptions is attached.
>
> On 12 February 2015 at 11:03, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
> >> Isnt this same as the Atom model with lld, lld uses symbol size to
> construct
> >> atoms.
> >
> > No, but IMHO it is what it *should* be :-)
> > These are still sections. You can have as many symbols in them as you
> > like. This lets you implement multiple entries, data close to code,
> > etc.
> >
> >> While this improves GC, what about :-
> >
> > It doesn't. What can be GCed with this patch is exactly what can be
> > gced with -ffunction-sections/-fdata-sections. This is only an
> > optimization on the size of the .o files.
> >
> >> a) linker script rules.
> >> b) how is COMDAT handled
> >> c) How are section relative relocations translated ? I believe it uses a
> >> section symbol + offset, how would this be taken care.
> >
> > Not changed at all. That is the nice thing about this strategy. The
> > rules are exactly the same as having multiple sections.
> >
> >>> As part of the work of upstreaming the llvm changes, I have been
> >>> looking at a way to view and implement this as a general and sound
> >>> optimization.
> >>>
> >>> In order to be able to split sections, the linker needs extra
> >>> relocations. In fact, it needs the same relocations as would be needed
> >>> if -ffunction-sections and -fdata-sections were used.
> >>
> >> Why dont we use -ffunction-sections and -fdata-sections by default.
> >
> > The two arguments I have heard are:
> >
> > * The overhead in size and link time.
> > * Different behavior from gcc.
> >
> > With this patch the overhead is down to about 1.06X on the size of the
> > .o files. I haven't timed the link time overhead when gc is not done,
> > but maybe once this is in we can reconsider
> > -ffunction-sections/-fdata-sections by default.
> >
> >> What is the alignment of each individual section that has been split ?
> >
> > My understanding is that it will have the same as it would have with a
> > plain -ffunction-section/-fdata-section or higher (if it just so
> > happens to end up more aligned).
> >
> >>> The patch needs a bit more work (proper option instead of cl::opt,
> >>> more compact encoding), but it can bootstrap and saves some space in
> >>> the .o files. In a build dir after running "ninja && ninja check-all"
> >>> the total size of the .o files goes from 237871087 bytes to 231292287.
> >>
> >> I couldnt follow how does this save space ?
> >
> > By avoiding long section names.
> >
> >>> The patch also offers some saving even when
> >>> -ffunction-sections/-fdata-sections are not used by avoiding long
> >>> names in comdats.
> >>>
> >>> The next step would then be to add an "implicit" flag in addition to
> >>> the "unique" one. This would mean that when given
> >>>
> >>> .section .text,"ax", at progbits, implicit
> >>> .section .text,"ax", at progbits, implicit
> >>
> >> How does partial linking work ?
> >
> > What do you mean by that? The implicit will not even survive to the
> > .o. It is  just a tool for creating the correct relocations in MC.
> >
> >>> With this in then the default for PS4 would be changed to
> >>> -ffunction-sections, -fdata-sections and implicit sections.
> >>>
> >>> The advantage of implementing it this way is that it makes it clear
> >>> that it is really just a .o compactness optimization. No extra logic
> >>> is required for deciding if a relocation is needed. The extra handling
> >>> of "implicit" would be just in the ELF object writer.
> >>
> >> Curious, is this planned in binutils too ?
> >
> > I am not planning on implementing it right now. It would be an extra
> > feature requiring the use of MC.
> >
> > Cheers,
> > Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150212/7a972a0d/attachment.html>