dead code removal

[Iain Buclaw via D.gnu]

On 30 Nov 2014 09:20, "Johannes Pfau via D.gnu" <d.gnu at puremagic.com> wrote:
>
> Am Sun, 30 Nov 2014 01:52:57 +0000
> schrieb "Mike" <none at none.com>:
>
> > This has been brought up before:
> > [1]
> > http://forum.dlang.org/post/cqzazaqxpwezignixuds@forum.dlang.org
> > [2]
> > http://forum.dlang.org/post/zapxhodqmotriapuefvm@forum.dlang.org
> >
> > But I'd like to know what GDC's long term plans are to enable
> > removing dead code from executables.
> >
> > (1) Adding a D-specific linker script in GDC that gets
> > automagically passed to the linker?
>
> AFAIK that's almost impossible. You can't replicate the complete linker
> scripts for all architectures with all their special cases etc. It
> could be possible to place all ModuleInfos in a special section then
> pass a implicit linker script which extends the standard script and
> only handles this section.
>
> > (2) Adding a D-specific linker script to binutils?
> > (3) LTO in GCC/binutils?
>
> LTO is certainly a long-time (though low priority) goal. AFAIK it's
> mostly about speed optimization though, not size.
>
> > (2) sounds a little weird, but I got the impression from
> > discussion [1] that that was part of the plan.  I don't
> > understand why binutils should have to know about D's codegen,
> > but there's a lot of things I don't understand.
>
> The linker scripts also know about some details of the C/C++ codegen.
> For example attribute(constructor) needs support from linker scripts.
> (KEEP, SORT_NONE, PROVIDE_HIDDEN or similar) Without this support
> constructor calls would be eliminated by these optimization flags as
> well. So it's kinda reasonable.
>

To contrast with another young language. Go/Android has linker support in
binutils when I last looked.  Heck, Go runtime even has Linux kernel
support code somewhere (though I don't think the core Linux devs liked it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20141130/50e2c7eb/attachment.html>