https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #31 from hubicka at kam dot mff.cuni.cz ---
> It likely was the loop header copying missing on cold loops then.
Yep. It is good we worked that out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #29 from Martin Liška ---
As seen here:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=299.170.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.170.0
the regression is fixed!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #28 from rguenther at suse dot de ---
On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
>
> --- Comment #27 from Aldy Hernandez ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #27 from Aldy Hernandez ---
(In reply to Richard Biener from comment #20)
> (In reply to hubicka from comment #19)
> > The testcase would be
> >
> > void test ()
> > {
> > int i;
> > if (test())
> > i=0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #26 from Richard Biener ---
(In reply to Richard Biener from comment #25)
> (In reply to rguent...@suse.de from comment #24)
> > On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
> >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #25 from Richard Biener ---
(In reply to rguent...@suse.de from comment #24)
> On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> >
> > --- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #24 from rguenther at suse dot de ---
On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
>
> --- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> > We verify that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> We verify that by simply looking at the loop depth relation of
> the entry and exit of the path.
Which seem wrong for the path leaving loop and entering another...
>
> > It seems to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #22 from rguenther at suse dot de ---
On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
>
> --- Comment #21 from hubicka at kam dot mff.cuni.cz ---
> > to also allow to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #21 from hubicka at kam dot mff.cuni.cz ---
> to also allow to thread through a loop path not crossing the latch but
> at least for the issue of "breaking loops" the loops_crossed stuff shouldn't
> be necessary. It might still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #20 from Richard Biener ---
(In reply to hubicka from comment #19)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> >
> > --- Comment #18 from Aldy Hernandez ---
> >
> > > If I read it correctly, for a path that enters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #19 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
>
> --- Comment #18 from Aldy Hernandez ---
>
> > If I read it correctly, for a path that enters the loop and later leaves
> > it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #18 from Aldy Hernandez ---
> If I read it correctly, for a path that enters the loop and later leaves
> it (where threading is desirable since we skip the whole loop) the logic
> above will still return true (after finishing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Aldy Hernandez changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #16 from hubicka at kam dot mff.cuni.cz ---
Note that it still seems to me that the crossed_loop_header handling is
overly conservative. We have:
@ -2771,6 +2771,7 @@ jt_path_registry::cancel_invalid_paths
(vec )
bool seen_latch
Note that it still seems to me that the crossed_loop_header handling is
overly conservative. We have:
@ -2771,6 +2771,7 @@ jt_path_registry::cancel_invalid_paths
(vec )
bool seen_latch = false;
int loops_crossed = 0;
bool crossed_latch = false;
+ bool crossed_loop_header = false;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #15 from rguenther at suse dot de ---
On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
>
> --- Comment #13 from Aldy Hernandez ---
> Since DOM is the only threading pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #14 from Martin Liška ---
I tend to close this issue due to a mismatch between train and reference run.
It's basically measuring speed of the cold code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #13 from Aldy Hernandez ---
Since DOM is the only threading pass that keeps more or less accurate
profiling data, here's a very wild guess.
The pre-loop DOM threading pass does not thread some paths because of
the restrictions in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #12 from Aldy Hernandez ---
It's been mentioned that this SPEC test has irreconcilable differences between
the train and peak runs, and cannot be reasonably compared. Is the slowdown
reported between two runs of compatible runs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #11 from Aldy Hernandez ---
>From what I gather, this is only reproducible with PGO. If so, it may be worth
nothing that Jeff has mentioned that the backward threader probably does not do
a very good job with keeping profile counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #10 from hubicka at kam dot mff.cuni.cz ---
>
> Hmmm, this commit disables problematic threads we've agreed are detrimental to
> loop form. So it's not something the threader did, but something it's not
> allowed to do. This PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #9 from Aldy Hernandez ---
(In reply to Martin Liška from comment #8)
> Started with Aldy's commit
> r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.
Hmmm, this commit disables problematic threads we've agreed are detrimental to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-11-01
Ever confirmed|0
25 matches
Mail list logo
