http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-12-15
Ever confirmed|0 |1
--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We should analyze why we end up with missing symbol. __attribute__ ((used))
will prevent privatization of the symbol. Rather than that it would be better
to figure out what object file of the library actually need it and look at the
preprocessed source code if the inline version is there.
I just rebuilt without testing and indeed it seems that cprop and df seems to
degenerate here quite noticeably.
It is lookupIntrinsicID that consume a lot of time and its CFG is not small:
$4 = {x_entry_block_ptr = 0x7ffff65b22d8, x_exit_block_ptr = 0x7ffff65b2340,
x_basic_block_info = 0x7ffff48df000, x_n_basic_blocks = 13898, x_n_edges =
22158,
x_last_basic_block = 13898, last_label_uid = 8660, x_label_to_block_map =
0x0, x_profile_status = PROFILE_GUESSED, x_dom_computed = {DOM_NONE, DOM_NONE},
x_n_bbs_in_dom_tree = {0, 0},
max_jumptable_ents = 34}
But it does not really explain why cprop should that that much of time.
It seems that the function is huge sequence of ifs compiling into:
<L3807>:
_3982 = &MEM[(void *)_5 + 31B];
_3983 = memcmp (_3982, "tore", 4);
if (_3983 != 0)
goto <bb 4208>;
else
goto <bb 5260>;
plus a lot of PHIs that probably makes cprop to work hard...
I wonder if we can't inline those stupid memcmps somehow.
Marking as NEW at least for the performance problem. Still unsure if the
original problem is source bug or GCC bug.
