http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #15)
> 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.
See PR52171.
