Unfortunately the proper fix did not make it to the mainlie (it probably
will
next stage1). Building kernel is however important. Can you please fill it
in
and mark it as a regression? I think I will implement a hack and track
everything
that refers user named labels and force it
On Sun, Mar 29, 2015 at 07:47:18AM +0200, Jan Hubicka wrote:
Hi,
I actually got idea how to make partitioning safe for named labels w/o
going the difficult
route of makeing them part of symbol table. Will look into that tonight or
tomorrow.
Also there's a juicy ICE with that
Unfortunately the proper fix did not make it to the mainlie (it probably will
next stage1). Building kernel is however important. Can you please fill it in
and mark it as a regression? I think I will implement a hack and track
everything
that refers user named labels and force it to
On Sun, Mar 29, 2015 at 07:47:18AM +0200, Jan Hubicka wrote:
Hi,
I actually got idea how to make partitioning safe for named labels w/o going
the difficult
route of makeing them part of symbol table. Will look into that tonight or
tomorrow.
Also there's a juicy ICE with that worked
On Sun, Mar 29, 2015 at 12:19:11AM +0100, Andi Kleen wrote:
I think this was the last major offender for Chromoim/Libreoffice and
Firefox.
(Modulo the fact htat chromium needs 9GB for WPA. There seems not be much of
low hanging fruit - chromium needs a lot of trees to be streamed in that
It doesn't build at all currently. The old problem with label jump table
initializers being spread incorrectly over partitions is back again, causing
the BPF interpret to throw a lot of
.tmp_vmlinux1.ltrans31.ltrans.o:(.data+0x32268): undefined reference to
`.L3'
I thought you had fixed
I think this was the last major offender for Chromoim/Libreoffice and Firefox.
(Modulo the fact htat chromium needs 9GB for WPA. There seems not be much of
low hanging fruit - chromium needs a lot of trees to be streamed in that will
hopefully be tracked by early debug soon.) What is the
Hi,
I actually got idea how to make partitioning safe for named labels w/o going
the difficult
route of makeing them part of symbol table. Will look into that tonight or
tomorrow.
Also there's a juicy ICE with that worked around:
/home/andi/lsrc/linux/drivers/scsi/bfa/bfa_ioc.c: In function
On Wed, 25 Mar 2015, Jan Hubicka wrote:
Hi,
linemap is optimized for situation where parser enters positions into it in
source order.
LTO does not work this way - it attach locations to trees and reads them more
or less
randomly. This results in large memory use of linemaps, slow lookups
Hello,
here is updated patch I intend to commit after bootstrap/regtest on
x86_64-linux and some additional testing on Chromium/libreoffice (it works
on Firefox).
I turned the cache into class. I tried to avoid global variable, but
ended up with the pointer to current cache because the use in
+ lto_apply_location_cache ();
+
Please add a comment here. It might be possible to write a
Will do.
lto_location_cache_decl_source_location (TYPE_NAME (t1)) that
looks if the location is in the cache and otherwise falls back to
DECL_SOURCE_LOCATION. That would be kind-of slow,
Hi,
linemap is optimized for situation where parser enters positions into it in
source order.
LTO does not work this way - it attach locations to trees and reads them more
or less
randomly. This results in large memory use of linemaps, slow lookups (that are
critical
for WPA stremaing) and as i
Jan Hubicka hubi...@ucw.cz writes:
Bootstrapped/regtested x86_64-linux, the patch saves about 1GB of locators
for chromium
and 400MB for firefox LTO.
Great. On my LTO builds linemap was always high up in the profiles too.
Yep, these was always high. I am re-running some profiles now.
Jan Hubicka hubi...@ucw.cz writes:
Bootstrapped/regtested x86_64-linux, the patch saves about 1GB of locators
for chromium
and 400MB for firefox LTO.
Great. On my LTO builds linemap was always high up in the profiles too.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
14 matches
Mail list logo
