Hi,
All the latent issues wthat ipa-devirt has triggered has been hopefully
fixed. So I am enabling ipa-devirt with LTO.
To answer original David's comment on non-LTO performance, I did not really
noticed
any significant improvements/dergradations at -O2 with our benchmarks (SPEC2k,
2k6
and C++ benchmarks). There are indeed some wrong guesses happening in eon, but
the code size effect is sub 1%. We also do not regularly benchmark much of code
that
would have virtual calls in the hot regions of code (I only know of xalanbmk
that is
already devirtualized in cases that are really hot)
LTO variant definitely improve firefox, but being very simple pass I am not
sure how high hopes one should have in general. The pass needs to be more
conetext sensitive to do something useful in sane code (i.e. code where virtual
keyword is there for a reason). I will send separate mail on this.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-devirt.c (ipa_devirt): Enable with LTO.
Index: ipa-devirt.c
===================================================================
--- ipa-devirt.c (revision 202445)
+++ ipa-devirt.c (working copy)
@@ -1128,7 +1128,7 @@ ipa_devirt (void)
static bool
gate_ipa_devirt (void)
{
- return flag_devirtualize_speculatively && !in_lto_p && optimize;
+ return flag_devirtualize_speculatively && optimize;
}
namespace {
