[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[rguenth at gcc dot gnu.org]

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.