On 09 Jan 2007 10:09:35 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> With LTO, an object file may contain sections with IL, which
> can be discarded when building DSO and executable. Currently we can't
> mark such sections with gABI. With GNU linker, we can use a
> linker script to discard such sections. But it will be more generic
> to make a section to be discarded for DSO and executable in gABI.
> In that case, we don't need a special linker script to discard
> such sections. Something like
>
> #define SHF_DISCARD 0x800
>
> would work.
That is not strictly required for LTO as I see it. With LTO, the lto
program is going to read the .o files with the IL information. It
will then generate a new .s file to pass to the assembler. The IL
information will never go through the linker.
Not only this isn't a requirement, there's a scenario where
you *want* to keep the IL inside LTO-optimized DSO and executables
for re-optimization.
With LTO and IL inside executables and DSO,
it becomes possible to do profile-collection without any source code
and re-optimize the binary. i.e. an executable can be released with IL inside,
and the user of the binary can choose to do profile collection
on their own input, and re-optimize the binary to squeeze more performance.
This scenario also improves the usability of the profile-feedback directed
optimization (by not requiring the source code access and the whole
build environment for profile feedback optimization).
Of course, it is also possible that LTO .o files with IL information
will be passed directly to the linker, for whatever reason. In that
case, we may want the linker to remove the IL information. This is
not substantially different from the linker's current ability to strip
debugging information on request.
It should be optional for the linker to remove the sections containing IL.
We probably want to have a new option to strip to remove such sections
as well as linker option to remove such sections.
So if you want to propose a solution for that, I think you should
consider how it can be used for debugging information as well. And I
don't think SHF_DISCARD is a good name. We don't want to arbitrarily
discard the data, we want to discard it in certain specific scenarios.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
