> Please also prioritize fixing P1s and avoid pushing in risky
> fixes for P2s that might end up causing regressions. We are still
> seeing way too many changes in the IPA area (hi Honza!).
Hello :)
GCC 5 is a busy release from IPA point of view indeed. Here is a quick summary
what is still on my radar for GCC-5:
Bug 62051 - [4.9/5 Regression] Undefined reference to vtable with -O2 and
-fdevirtualize-speculatively
I think this one can be waved away as invalid code though tracking types with
visibility default
attached to it may be a safe fix and may make transition to GCC 5 smoother.
I do not think it should be P1
Bug 65475 - [5 Regression] ICE in odr_vtable_hasher::equal (segmentation fault)
Segfault is fixed (so no longer P1 IMO) I want to tamn down the verbosity of
ODR violation
warnings at weekend (we probably do not want more than one warning per type)
Bug 64860 - [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works))
This is about incremental linking with LTO but without Andi's patches to make
it actually work.
I think we can fix the linker errors eaisly (will do so soon), but I do not
see much utility in it.
Bug 61886 - [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
This one I think may need to wait for 5.2. I have fix in works and it is not
too intrusiove so far.
My main concern is about getting aliases more commonly appearing and exposing
semi-latent bugs.
We did a lot of progress making them work thanks to ICF making aliases
mainstream. Main issue IMO
is with alias analysis (that is not hit by ICF), but to fix 61886 we may want
to introduce the
transparent aliases only for function symbols that is IMO quite safe. Once I
am done I will post
full patch for RMs to consider.
We still have some inliner performance issues:
- I analyzed bzip, crafty and regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
The first one is easy to fix at ipa-cp side that I hope Martin will look
into
- Igor reports eon regression I plan to analyze on weekend
- tramp3d is about 10% above GCC 4.9 codesize - I think this is fine.
trakced in:
Bug 65076 - [5 Regression] 16% tramp3d-v4.cpp compile time regression
There are two parameter tweeks I am considering (and running benchamrks over
weekend):
- We may run into issues with current 15% unit growth is bit too tight. I
am planning to re-benchmark
firefox and see if bumping to 20% makes useful difference. With all
bugfixes in area it may not
- -fprofile-use inlining has currently no bound on size of function to
inline when call is considered
resonably hot. This makes me bit nervous and I may limit it by
inline-insns-single without LTO.
(with LTO overall unit growth works well)
Chromium and Firefox has some ODR violation warnings that may need a bit of
love. I think there are some that
are just invalid (need to double check) and we get some unwanted verbosity here
too.
ICF at Chromium needs 15% of WPA time (and saves 10% size in addition to gold
ICF). Martin has patches
to improve hashing, one was approved the other (adding simple hash for types)
will be hopefully done
by Monday.
Honza
