https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 48724, which changed state.
Bug 48724 Summary: Lto build of mozilla dies at lto-wrapper: error trying to
exec 'make -j1': execvp: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #219 from Jan Hubicka ---
devirtualization issue is now fixed, so we are down to -fno-lifetime-dse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #218 from Martin Liška ---
Hi.
Building Firefox revision:
commit a704d34fb1f9e0f5dbf4113298d885cdb650906c
Author: Matthew Noorenberghe
Date: Thu Dec 3 17:33:35 2015 -0800
Bug 1230391 - Disable password visibility toggling in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #217 from Jan Hubicka ---
Author: hubicka
Date: Tue Jan 20 19:48:59 2015
New Revision: 219909
URL: https://gcc.gnu.org/viewcvs?rev=219909&root=gcc&view=rev
Log:
PR lto/45375
* ipa-inline.c: Include lto-streamer.h
(report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #216 from Jan Hubicka ---
Author: hubicka
Date: Tue Jan 20 04:39:45 2015
New Revision: 219878
URL: https://gcc.gnu.org/viewcvs?rev=219878&root=gcc&view=rev
Log:
PR lto/45375
* i386.c (ix86_option_override_internal): Use ix86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #215 from Jan Hubicka ---
Author: hubicka
Date: Mon Jan 19 23:58:19 2015
New Revision: 219871
URL: https://gcc.gnu.org/viewcvs?rev=219871&root=gcc&view=rev
Log:
PR lto/45375
* i386.c (gate): Check flag_expensive_optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #213 from Steffen Hau ---
Hi Jan,
just a short Update: Firefox since version 30 as well as Thunderbird since
version 31 both compile fine with LTO enabled without the need of any
additional patches. The package size was reduced by 51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #212 from Steffen Hau ---
Hi Jan,
I have binutils version 2.24 with the patch from Markus Trippelsdorf for early
plugin loading, so I have no wrappers for ar, nm and ranlib. I've also
symlinked the liblto_plugin.so in binutils bfd-pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #211 from Jan Hubicka ---
Elfhack is rather sensitive to LTO, but it works for me, so this seems like
binutils issue or some elfhack change that happened recently.
I wrote instructions for building firefox with LTO here
http://hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Steffen Hau changed:
What|Removed |Added
CC||steffen at hauihau dot de
--- Comment #210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #209 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #208)
> Both issues from Comment 201 were fixed by:
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00338.html
No, only the first issue is fixed. The secon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #208 from Markus Trippelsdorf ---
Both issues from Comment 201 were fixed by:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00338.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #207 from Martin Liška ---
Created attachment 32525
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32525&action=edit
Memory usage graphs for -flto=9, -flto=4, -flto=1 with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #206 from Martin Liška ---
Firefox (and chromium) memory reports with -flto=9 and -O2; archive contains
also memory usage graph:
https://docs.google.com/file/d/0B0pisUJ80pO1bnV5V0RtWXJkaVU/edit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #205 from Jan Hubicka ---
I was looking into this recently, too. Curiously enough, for me clang+LTO was
winning
but comparing the symbols it seemed that the confiugre scripts picked bit more
features
at GCC side. I looked briefly on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #204 from Markus Trippelsdorf ---
Here is a comparison of libxul sizes (in bytes, unstripped) for different
compiler options:
gcc (trunk):
-O3 90213016
-O3 -flto 79682648
-O3 -flto / PGO 77250512
-Os 7043
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #203 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #202)
> LTO miscompiles 435.gromacs in SPEC CPU 2006 on x32 with
>
> -mx32 -O3 -funroll-loops -ffast-math
>
> since r208165 (PR 60418). Can you try r208163?
Yes. U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #202 from H.J. Lu ---
LTO miscompiles 435.gromacs in SPEC CPU 2006 on x32 with
-mx32 -O3 -funroll-loops -ffast-math
since r208165 (PR 60418). Can you try r208163?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #201 from Markus Trippelsdorf ---
With current gcc trunk and mozilla-central trunk Firefox crashes on startup
when
build with -flto (--enable-optimize=-O3):
0x75ce5d8f in nsCOMPtr_base::assign_with_AddRef(nsISupports*) [clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #200 from Martin Jambor ---
I currently cannot build Firefox with LTO due to PR 60449 (yeah, I
know, using gcc configured with checking makes life hard, sometimes
unnecessarily).
I get errors like
/home/mjambor/mozilla/mzc2/media/lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #199 from Markus Trippelsdorf ---
Created attachment 31878
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31878&action=edit
.mozconfig_profile_gen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #198 from Markus Trippelsdorf ---
Created attachment 31877
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31877&action=edit
My local PGO/LTO script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #196 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #195)
> Today there was two fixes for bugs that produce undefined symbols like one
> you see.
> Does the problem still exist on current mainline? Are you using pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #195 from Jan Hubicka ---
Today there was two fixes for bugs that produce undefined symbols like one you
see.
Does the problem still exist on current mainline? Are you using profile
feedback?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #194 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #193)
> I am building firefox with -O3 and get no undefined symbols. Can you,
> please, relink with -Wl,--no-demangle --save-temps -fdump-ipa-all and try to
> loo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #193 from Jan Hubicka ---
I am building firefox with -O3 and get no undefined symbols. Can you, please,
relink with -Wl,--no-demangle --save-temps -fdump-ipa-all and try to look up
the missing symbol in -lm.res file and if it not UNDE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #192 from Markus Trippelsdorf ---
It turned out that -enable-optimize=-O3 is the cause.
Rev202079 with -Os links fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #191 from Markus Trippelsdorf ---
First of all many thanks for your work on reducing memory usage.
Peak memory usage is now lower (~3GB) than clang's (~4GB).
However, with -enable-optimize=-O3 on rev202079 I get:
(An default (-Os) bui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #190 from Jan Hubicka ---
> /ssd/firefox/js/src/gc/Marking.cpp: In function
> ???js::gc::IsAboutToBeFinalized(JSAtom**)bool [clone .isra.65]???:
> /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
> profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #187 from Jan Hubicka ---
WPA time report
Execution times (seconds)
phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
1398 kB ( 0%) ggc
phase opt and generate : 80.79 (13%) usr 1.01 ( 3%) sys 81.96
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #186 from Jan Hubicka ---
oprofile of merging
6764713.0501 lto1 inflate_fast
38682 7.4624 lto1 compare_tree_sccs_1(tree_node*,
tree_node*, tree_node***)
32365 6.2437 lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #185 from Jan Hubicka ---
I merged in some patches intended to reduce memory of Firefox LTO and also
updated firefox tree. Some more involved patches are on the way, so it is
summary where we stand now.
WPA usage in TOP is 10GB now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #184 from Jan Hubicka ---
New profiles after Richard's changes to remove pointer maps from straming in.
Stream in:
samples %app name symbol name
3659912.3464 lto1 inflate_fast
27382
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #183 from Jan Hubicka ---
type merging stats
[WPA] read 43156894 SCCs of average size 2.270660
[WPA] 97994652 tree bodies read in total
[WPA] tree SCC table: size 8388593, 3830511 elements, collision ratio: 0.684487
[WPA] tree SCC max
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #182 from Jan Hubicka ---
OK, after a while I should update the stats here. Richard's new tree merging
patch makes libxul linking a lot faster and less memory consuming.
Peak memory usage (in TOP) is now just bellow 10GB, with bit of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Martin Jambor changed:
What|Removed |Added
Depends on||56570
--- Comment #181 from Mar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #180 from Richard Biener 2013-03-07
16:08:29 UTC ---
Try
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 196520)
+++ gcc/tree-inline.c (workin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #179 from Martin Jambor 2013-03-06
15:14:35 UTC ---
I'm currently (gcc revision 196427, FF changeset 123831:c95439870e05)
facing a few ICEs during the compilation phase with the following
backtrace:
#0 0x00f89a73 in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #178 from Jan Hubicka 2013-01-17
17:11:13 UTC ---
The global cache with arbitrary large size reduces usage down to 0.3%
(16908304) bytes. So it seems that sharing across files is quite an important
part of the game. I will try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #177 from Jan Hubicka 2013-01-17
15:13:53 UTC ---
Created attachment 29192
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29192
caching
Aha, now I see why you ask for complete patch. I obviously messed up the code.
Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #176 from Richard Biener 2013-01-17
14:54:22 UTC ---
(In reply to comment #175)
> Created attachment 29191 [details]
> alternative patch without the compression.
>
> This is alternative patch just skipping columns but not do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #175 from Jan Hubicka 2013-01-17
14:40:04 UTC ---
Created attachment 29191
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29191
alternative patch without the compression.
This is alternative patch just skipping columns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #173 from Jan Hubicka 2013-01-17 12:30:30
UTC ---
> Patch looks incomplete? What does dropping columns only do to memory use?
I will check. I remember that prior columns there was also some savings for
the cache.
Just savi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #172 from Richard Biener 2013-01-17
10:53:29 UTC ---
(In reply to comment #171)
> Created attachment 29182 [details]
> Patch to compress line info
>
> This patch removes column information from LTO (so we lose carret diagnos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #171 from Jan Hubicka 2013-01-16
17:25:04 UTC ---
Created attachment 29182
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29182
Patch to compress line info
This patch removes column information from LTO (so we lose carr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #170 from Jan Hubicka 2013-01-10
15:04:10 UTC ---
OK, here is updated memory use:
cgraph.c:863 (cgraph_allocate_init_indirect_info5905200: 0.1% 0:
0.0%6020160: 0.1% 0: 0.0% 298134
tree.c:1237 (bui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #169 from Jan Hubicka 2013-01-09
21:22:33 UTC ---
Author: hubicka
Date: Wed Jan 9 21:22:26 2013
New Revision: 195066
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195066
Log:
PR lto/45375
* ipa-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #168 from Jan Hubicka 2013-01-09
21:20:46 UTC ---
Too bad :(
The patch should reduce memory usage, not increase it. So it must be something
else.
My build was around 7GB w/o PGO, I will need to try the PGO builds myself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #167 from Markus Trippelsdorf
2013-01-09 19:58:33 UTC ---
(In reply to comment #166)
> Markus, the apperance of undefined references I fixed by patch above is highly
> sensitive to partitioning and inlining decision. Can you,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #166 from Jan Hubicka 2013-01-09
15:19:41 UTC ---
Markus, the apperance of undefined references I fixed by patch above is highly
sensitive to partitioning and inlining decision. Can you, please, check if the
problem with PGO r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #165 from Jan Hubicka 2013-01-09
15:16:26 UTC ---
OK, I tracked down the undefined reference to
error: /tmp/cc0oq4BG.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc
against '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Leo Yuriev changed:
What|Removed |Added
CC||leo at yuriev dot ru
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #163 from Jan Hubicka 2012-12-14 18:24:31
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #162 from Markus Trippelsdorf
> 2012-12-13 22:25:27 UTC ---
> The libxul binary size issue is solved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #162 from Markus Trippelsdorf
2012-12-13 22:25:27 UTC ---
The libxul binary size issue is solved now.
During testing I came across another issue that looks similar
to the one Comment 146:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #161 from Markus Trippelsdorf
2012-12-13 12:59:59 UTC ---
I've opened a new bug for the binary size increase issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #160 from Markus Trippelsdorf
2012-12-13 09:52:37 UTC ---
(In reply to comment #159)
> > hal/Hal.gcda: 96.72%: num counts=30069, min counter=16389
> > hal/Hal.gcda: 97.50%: num counts=35296, min counter=10241
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #159 from Jan Hubicka 2012-12-12 20:35:37
UTC ---
> hal/Hal.gcda: 96.72%: num counts=30069, min counter=16389
> hal/Hal.gcda: 97.50%: num counts=35296, min counter=10241
> hal/Hal.gcda: 98.28%: num
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #158 from Teresa Johnson 2012-12-12
18:59:56 UTC ---
On Wed, Dec 12, 2012 at 3:43 AM, markus at trippelsdorf dot de
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #157 from Markus Trippelsdorf
> 2012-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #157 from Markus Trippelsdorf
2012-12-12 11:43:27 UTC ---
With revision 193740 libxul's size is ~34MB, which is OK.
(Unfortunately this new ICE happens with yesterdays gcc when linking libxul:
/var/tmp/mozilla-central/content/base/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #156 from Teresa Johnson 2012-12-12
00:00:17 UTC ---
On Tue, Dec 11, 2012 at 2:57 PM, markus at trippelsdorf dot de
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #155 from Markus Trippelsdorf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #155 from Markus Trippelsdorf
2012-12-11 22:57:14 UTC ---
(In reply to comment #154)
> What was the size of the gcc lto/pgo binary before the change to use the
> histogram? Was it close to the gcc 4.7 lto/pgo size? In that case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #154 from Teresa Johnson 2012-12-11
19:30:53 UTC ---
What was the size of the gcc lto/pgo binary before the change to use the
histogram? Was it close to the gcc 4.7 lto/pgo size? In that case that is a
very large increase, ~25%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #153 from Markus Trippelsdorf
2012-12-02 21:13:21 UTC ---
On 2012.12.02 at 21:09 +, hubicka at ucw dot cz wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #152 from Jan Hubicka 2012-12-02 21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #152 from Jan Hubicka 2012-12-02 21:09:24
UTC ---
Also I suppose you don't have comparsion to 4.7 handy? (I am curious because of
inliner heuristic re-tunning)
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #151 from Jan Hubicka 2012-12-02 20:52:13
UTC ---
Teresa comitted another bugfix just today. So with bit of luck it will work
now?
I will try to look deeper into it ASAP, but I am just getting ready for trip to
USA.
Honza
Teresa comitted another bugfix just today. So with bit of luck it will work now?
I will try to look deeper into it ASAP, but I am just getting ready for trip to
USA.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #150 from Markus Trippelsdorf
2012-12-02 18:03:28 UTC ---
For comparison I've just disabled skia and build with LTO only;
the size looks good for this case: 31356968
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #149 from Jan Hubicka 2012-12-02 15:05:52
UTC ---
> > Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some
> > regressions
> > on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it
> > would b
> > Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some
> > regressions
> > on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it
> > would be
> > nice to know what value is needed for comparable size.
>
> Unfortunately it doesn't help much, because with "--para
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #148 from Markus Trippelsdorf
2012-12-02 11:57:27 UTC ---
(In reply to comment #147)
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
> >
> > --- Comment #146 from Markus Trippelsdorf
> > 2012-12-02 07:36:02 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #147 from Jan Hubicka 2012-12-02 09:23:09
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #146 from Markus Trippelsdorf
> 2012-12-02 07:36:02 UTC ---
> (In reply to comment #145)
> > >
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #146 from Markus Trippelsdorf
2012-12-02 07:36:02 UTC ---
(In reply to comment #145)
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
> >
> > --- Comment #144 from Markus Trippelsdorf
> > 2012-12-01 12:39:30 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #145 from Jan Hubicka 2012-12-01 22:09:07
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #144 from Markus Trippelsdorf
> 2012-12-01 12:39:30 UTC ---
> It looks like there is a LTO code-size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #144 from Markus Trippelsdorf
2012-12-01 12:39:30 UTC ---
It looks like there is a LTO code-size regression on trunk:
(size of libxul.so, build without elfhack):
gcc lto/pgo : size: 42204584 | Kraken bench: 2723.9ms +/- 0.9%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #143 from Steven Bosscher 2012-10-08
22:30:20 UTC ---
Created attachment 28395
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28395
Use size_t for tree code book-keeping
...because overflow looks so sloppy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #142 from Jan Hubicka 2012-10-08
22:19:55 UTC ---
After updating Mozilla this weekend, I definitely bloat up 8GB machine. The pak
in TOP is around 9-10GB. I checked malloc usage and there are not many
surprises. It is about 30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #141 from Markus Trippelsdorf
2012-09-15 14:05:38 UTC ---
After the new IonMonkey JIT went in
(http://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-firefox-18/)
peak memory use went up. It is now 6.8GB (gcc-4.7 roughly the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #140 from Jan Hubicka 2012-08-19
05:55:26 UTC ---
Author: hubicka
Date: Sun Aug 19 05:55:20 2012
New Revision: 190509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190509
Log:
PR lto/45375
* ipa-inline.c (want_inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #139 from Jan Hubicka 2012-08-18
09:36:55 UTC ---
oprofile of WPA:
649295 18.2243 lto1 lto1 lto_main()
3412569.5783 lto1 lto1
htab_find_slot_with_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #138 from Jan Hubicka 2012-08-10
15:35:44 UTC ---
Actually not, I looked up wrong report. The last report in comment #121 shows:
TOTAL : 616.4322.26 651.79
2165706 kB
So we actually go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #137 from Jan Hubicka 2012-08-10
15:06:51 UTC ---
So since the last report we managed to double WPA memory usage and compile
time...
12m wall, 42m user is needed for WPA build.
Execution times (seconds)
phase opt and generate : 97.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #136 from Jan Hubicka 2012-05-13
16:29:04 UTC ---
... and oprofile of compilation stage of -flto-partition=none
samples %image name app name symbol name
1949762.8536 lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #135 from Jan Hubicka 2012-05-12
21:33:36 UTC ---
... and mem reports on WPA stage:
toplev.c:964 (realloc_for_line_map) 0: 0.0% 89473168:
9.4% 268435472:10.3%160: 0.0% 8
cgraph.c:359 (cgraph_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #134 from Jan Hubicka 2012-05-12
20:22:27 UTC ---
I tracked down the LTO/WHOPR code size difference. It is EH handling. EH frame
is empty for LTO build and quite large for WHOPR. Probably -fno-exceptions
getting lots on way to ltrans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #133 from Jan Hubicka 2012-05-12 19:07:32
UTC ---
Another thing to observe is that GGC memory is "just" 4GB. I am not sure where
the other 8GB goes when our IL is believed
to be major memory consumer and it resists almost completely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #132 from Jan Hubicka 2012-05-12 18:32:14
UTC ---
> > tree VRP: 65.88 ( 2%) usr 0.73 ( 2%) sys 66.71
> >( 2%) wall 862879 kB (24%) ggc
>
> Is it possible to do this again with gathering statistics enabled? The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #130 from Jan Hubicka 2012-05-12
14:44:47 UTC ---
After fixing one linker error, I can now build Mozilla with
-flto-partition=none. It takes 11GB and 40 minutes, so there is space for
improvement ;)
There are some obvious questions,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #129 from Jan Hubicka 2012-05-11
19:05:19 UTC ---
OK, the slow part of uniuqify_nodes is:
/* Remove us from our main variant list if we are not the
variant leader. */
if (TYPE_MAIN_VARIANT (t) != t)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #128 from Jan Hubicka 2012-05-11 08:52:50
UTC ---
> Well - the obvious possibly "slow" part of uniquify nodes is that it walks
> all fields of record/union types. So - do you have a more detailed profile
> of uniquify_nodes?
No, I w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #127 from Mike Hommey 2012-05-11
08:52:24 UTC ---
(In reply to comment #126)
> (In reply to comment #124)
> > > Just for comparison, clang with -O4 runs only single threaded and does
> > > everything in memory (no streaming out). It u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #126 from Markus Trippelsdorf
2012-05-11 08:46:39 UTC ---
(In reply to comment #124)
> > Just for comparison, clang with -O4 runs only single threaded and does
> > everything in memory (no streaming out). It uses 3.5GB of memory (peak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #125 from Richard Guenther 2012-05-11
08:44:51 UTC ---
(In reply to comment #122)
> oprofile shows:
> 139188 15.6963 lto1 lto1
> uniquify_nodes
> 66390 7.4868 lto1 lt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #124 from Jan Hubicka 2012-05-11 08:34:17
UTC ---
> Just for comparison, clang with -O4 runs only single threaded and does
> everything in memory (no streaming out). It uses 3.5GB of memory (peak) and
> takes 19 minutes to finish...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #123 from Markus Trippelsdorf
2012-05-11 05:55:43 UTC ---
Just for comparison, clang with -O4 runs only single threaded and does
everything in memory (no streaming out). It uses 3.5GB of memory (peak) and
takes 19 minutes to finish...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #122 from Jan Hubicka 2012-05-10
21:53:54 UTC ---
oprofile shows:
139188 15.6963 lto1 lto1
uniquify_nodes
66390 7.4868 lto1 lto1
estimate_edge_gro
1 - 100 of 216 matches
Mail list logo
