https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89992
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-04-08
CC| |hubicka at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
Summary|Vectorizer is very |Vectorizer is sensitive to
|sensitive to function calls |guessed profile
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's simply that inlining makes the guessed profile not consider the loop worth
optimizing for speed. Part of that is because the loop ends up in main()
which we know is executed exactly once and bb->count is less than the entry
block count so we hit
maybe_hot_count_p (struct function *fun, profile_count count)
{
...
if (node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
&& count < (ENTRY_BLOCK_PTR_FOR_FN (fun)->count.apply_scale (2, 3)))
return false;
this is probably due to predictors saying that
if (__eax <= 6)
return 0; // return from main
is likely (it gets 66% hit predicted). The foo() != 0 gets even probability
and the following == 230 test gets only 11% probability to hit.
The "fun" of static profile... (and doing benchmarking in main()).
But it doesn't have anything to do with the vectorizer or calls.
