On Wed, Nov 25, 2015 at 12:59 AM, Jan Hubicka wrote:
> Hi,
> PR 67548 is about LTO not supporting incremental linking. I never really
> considered our current incremental linking very useful, because it triggers
> code generation at the incremental link time basically nullifying any
> benefits of
>
> 2015-11-28 Tom de Vries
>
> * lto-wrapper.c (run_gcc): Handle -flinker-output argument.
Thanks, this looks fine to me. THe way options are handled in lto-wrapper
seems like a gross hack. Hopefully we will manage to clean this up eventually.
What happens when I call one of input ob
On 28/11/15 13:02, Ilya Verbin wrote:
2015-11-28 14:01 GMT+03:00 Tom de Vries :
This patch fixes the failures. I'm not sure if this is the right or complete
fix though.
I think it's ok, at least until we decide how to rework the offloading
stuff in lto-wrapper (see PR68463).
Bootstrapped an
2015-11-28 14:01 GMT+03:00 Tom de Vries :
> This patch fixes the failures. I'm not sure if this is the right or complete
> fix though.
I think it's ok, at least until we decide how to rework the offloading
stuff in lto-wrapper (see PR68463).
Thanks,
-- Ilya
On 28/11/15 10:35, Tom de Vries wrote:
On 26/11/15 00:07, Jan Hubicka wrote:
(flinker_output): New flag.
Hi,
this seems to have cause a regression when using a compiler configured
for offloading (giving ~1000 fails in libgomp testing).
For test-case libgomp.c/examples-4/array_sections-3.c, w
On 26/11/15 00:07, Jan Hubicka wrote:
(flinker_output): New flag.
Hi,
this seems to have cause a regression when using a compiler configured
for offloading (giving ~1000 fails in libgomp testing).
For test-case libgomp.c/examples-4/array_sections-3.c, we enter run_gcc
in lto-wrapper with a
>
> what about allowing -flinker-output=XXX at link time as a driver option
> and avoiding to override it if already present?
That sounds good. I will implement that.
>
> > > >struct cgraph_node *node = order[i];
> > > >
> > > > - if (node->has_gimple_body_p ())
> > > > + if
On Thu, 26 Nov 2015, Jan Hubicka wrote:
> > > Moreover we do have all infrastructure ready to implement 3). Our tree
> > > merging
> > > and symbol table handling is fuly incremental and I think made a patch to
> > > implement it today. The scheme is easy:
> >
> > What happens when .S (assem
On Wed, 25 Nov 2015, Jan Hubicka wrote:
> > >
> > > 1) linker plugin is modified to pass -flinker-output to lto wrapper
> > > linker-output is either dyn (.so), pie or exec
> > > for incremental linking I added .rel for 3) and noltorel for 1)
> > >
> > > currently it does rel becaus
> > Actually I think it is harder than that, because we need to strip LTO data
> > from the object files, so we do not end up with duplicated LTO if the object
> > file was already having both LTO and non-LTO stuff in it.
>
> When I started with LTO I was looking into that, and that is why I origi
On Thu, Nov 26, 2015 at 02:55:04AM +0100, Jan Hubicka wrote:
> >
> > > I suppose we could play a games here with slim LTO: claim the file, see if
> > > there are any symbols defined in the non-LTO symbol table and if so,
> > > interpret
> > > read the symbol table and tell linker about the symbol
> > > In theory we could change the build system to avoid that case though, but
> > > it would need some changes.
> > >
> > > It would be better if that could be handled somehow.
> >
> > How does this work with your patchset? Ideally we should have way to claim
> > only portions of object files,
> > In theory we could change the build system to avoid that case though, but
> > it would need some changes.
> >
> > It would be better if that could be handled somehow.
>
> How does this work with your patchset? Ideally we should have way to claim
> only portions of object files, but we don't
> > Moreover we do have all infrastructure ready to implement 3). Our tree
> > merging
> > and symbol table handling is fuly incremental and I think made a patch to
> > implement it today. The scheme is easy:
>
> What happens when .S (assembler) files are part of the incremential object?
> Th
> Moreover we do have all infrastructure ready to implement 3). Our tree
> merging
> and symbol table handling is fuly incremental and I think made a patch to
> implement it today. The scheme is easy:
What happens when .S (assembler) files are part of the incremential object?
The kernel does
> Your patch means that Andis/HJs work is no longer needed and we can
> drop the section suffixes again?
Doing that would break existing setups that do ld -r instead of gcc -r
Maybe longer term.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
Hi,
here is the patch that implement incremental LTO linking. I will wait few days
for feedback. gcc -r now does LTO IL linking only. To force codegen, one can
use -Wl,-rnolto which I found no right place to document. We may want -rnolto
flag uspported by GCC driver, so the testsuite can be upd
Hi,
this is the first part of patch that adds -flinker-output flags and gets symbol
visibility right. It makes the testcase in the PR to pass, but I do not know
how to turn it into a testsuite ready version.
I remember there was other PRs related to incremental linking and symbol
visibility,
I wi
> >
> > Your patch means that Andis/HJs work is no longer needed and we can
> > drop the section suffixes again?
> >
> >
>
> There is a difference between "ld -r " and "gcc -r". "ld -r" may not
> perform any LTO.
Theoretically ld -r may look up for the linker plugin on it search path that
will
i
> >
> > 1) linker plugin is modified to pass -flinker-output to lto wrapper
> > linker-output is either dyn (.so), pie or exec
> > for incremental linking I added .rel for 3) and noltorel for 1)
> >
> > currently it does rel because 3) (nor 2) can not be done when
> > incremnetal
>
On Wed, Nov 25, 2015 at 3:15 AM, Richard Biener wrote:
> On Wed, 25 Nov 2015, Jan Hubicka wrote:
>
>> Hi,
>> PR 67548 is about LTO not supporting incremental linking. I never really
>> considered our current incremental linking very useful, because it triggers
>> code generation at the incrementa
On Wed, 25 Nov 2015, Jan Hubicka wrote:
> Hi,
> PR 67548 is about LTO not supporting incremental linking. I never really
> considered our current incremental linking very useful, because it triggers
> code generation at the incremental link time basically nullifying any
> benefits of whole progra
Hi,
PR 67548 is about LTO not supporting incremental linking. I never really
considered our current incremental linking very useful, because it triggers
code generation at the incremental link time basically nullifying any
benefits of whole program optimization and in fact I think it is harmful,
b
23 matches
Mail list logo
