https://sourceware.org/bugzilla/show_bug.cgi?id=18178
Bug ID: 18178
Summary: Plugin API extensions needed to support incremental
linking with LTO
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hubicka at gcc dot gnu.org
CC: ian at airs dot com
Hello,
there seems to be 3 answers to what should be incremntal linking with LTO
1) incremental linker should just unify all the LTO sections to one .o file
that will be processed at final link-time
2) incremental linker should invoke LTO optimizer and optimize the part of
program
3) incremental linker should invoke LTO optimizer to merge the sections (and do
type linking) into the .o file that will be smaller than one produced by 1)
HJ's binutils support 1, but this was never merged to mainline binutils.
With mainline we sort of try to do 2 but there is a problem. GCC makes an
assomptions that static linking will not happen post LTO optimizations and
perform optimizations that breaks it (such as turning codats into non-weak
symbols and dissolving comdat groups). I think we need a way to inform GCC that
static linking is expected to happen. Either globally (by some flag) or locally
per symbol basic. That would mean extending PREVAILING_DEF to
PREVAILING_DEF_INCREMENTAL specifying that incremental linking is possible.
We could also try to support 3 that would be IMO best answer to the problem.
Here I guess most work is at the linker side - we need to add flag to GCC to
stream out IL again after merging and unreachable code removal. This should be
easy to do. Linker however needs to be updated to put the resulting LTO section
into object file and combine it with non-LTO sections...
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
