https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #25 from Richard Biener ---
(In reply to Jan Hubicka from comment #24)
> g:2e93b92c1ec5fbbbe10765c6e059c3c90d564245 fixes the profile update after
> cancelled distribution. However it does not help hmmer since we actually
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #24 from Jan Hubicka ---
g:2e93b92c1ec5fbbbe10765c6e059c3c90d564245 fixes the profile update after
cancelled distribution. However it does not help hmmer since we actually
vectorize that loop iterating 0 times. We need to figure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #23 from Jan Hubicka ---
Thanks,
I think I will need to work out the remaining vectorizer problems. One issue
seems to be interaction with loop distribution. Loop distribution seems to
intorduce alias checks that are later removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #22 from Martin Jambor ---
(In reply to Jan Hubicka from comment #21)
> Fixing loop distribution and vectorizer profile update seems to do the trick
> with profile feedback. Without we are still worse than in July last year on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #21 from Jan Hubicka ---
Fixing loop distribution and vectorizer profile update seems to do the trick
with profile feedback. Without we are still worse than in July last year on
zen2 tester (zen3 and ice lake seems to behave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #20 from rguenther at suse dot de ---
On Fri, 28 Jul 2023, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
>
> --- Comment #19 from Jan Hubicka ---
> > This heuristic wants to catch
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #19 from Jan Hubicka ---
> This heuristic wants to catch
>
>
> if (foo) abort ();
>
>
> and avoid sinking "too far" across a path with "similar enough"
> execution count (I think the original motivation was to fix some
>
> This heuristic wants to catch
>
>
> if (foo) abort ();
>
>
> and avoid sinking "too far" across a path with "similar enough"
> execution count (I think the original motivation was to fix some
> spilling / register pressure issue). The loop depth test
> should be !(bb_loop_depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:b24acae8f4d315a5b071ffc2574ce91c7a0800ca
commit r14-2850-gb24acae8f4d315a5b071ffc2574ce91c7a0800ca
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #16 from Jan Hubicka ---
It is really hard to make loop splitting to do something.
It does not like canonicalized invariant variables since loop exit condition
should not be NE_EXPR and it does not like when VRP turns LT/GT into NE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #15 from Jan Hubicka ---
if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
/* If result of comparsion is unknown, prefer EARLY_BB.
Thus use !(...>=..) rather than (...<...) */
- && !(best_bb->count *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #14 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Richard Biener changed:
What|Removed |Added
Target Milestone|13.0|13.2
--- Comment #13 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #12 from Martin Jambor ---
My understanding of comment #2 and #3 is that we end up with what are very
likely bogus BB counts that we should check and perhaps attempt to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
15 matches
Mail list logo
