It is frustrating that virtually all the regressions with the hybrid
threader for VRP, have not been with the engine itself, but with the
independent restrictions we have agreed upon.
The following patch is a collection of discussions with Richi, Jeff,
and Michael Matz regarding jump threading lim
On 10/4/2021 3:43 AM, Aldy Hernandez wrote:
It is frustrating that virtually all the regressions with the hybrid
threader for VRP, have not been with the engine itself, but with the
independent restrictions we have agreed upon.
The following patch is a collection of discussions with Richi, Je
Note that none of the other tests have been adjusted so it'll likely result
in multiple threading regressions.
Thanks for looking at this.
Aldy
On Mon, Oct 4, 2021, 15:31 Jeff Law wrote:
>
>
> On 10/4/2021 3:43 AM, Aldy Hernandez wrote:
> > It is frustrating that virtually all the regressions
On 10/4/2021 7:36 AM, Aldy Hernandez wrote:
Note that none of the other tests have been adjusted so it'll likely
result in multiple threading regressions.
Yea ;-) So maybe we first focus on how those affect visium since that's
what started us down this path.
The original test of regression
Hello,
On Mon, 4 Oct 2021, Jeff Law wrote:
> And just in case it got lost. Here's the analysis on 960218-1 on visium:
>
> We've got this going into ethread:
>
> int f (int x)
> {
> int D.1420;
> int a;
>
> ;; basic block 2, loop depth 0, maybe hot
> ;; prev block 0, next block 3, fla
On Mon, Oct 4, 2021 at 6:29 PM Michael Matz wrote:
>
> Hello,
>
> On Mon, 4 Oct 2021, Jeff Law wrote:
>
> > And just in case it got lost. Here's the analysis on 960218-1 on visium:
> >
> > We've got this going into ethread:
> >
> > int f (int x)
> > {
> > int D.1420;
> > int a;
> >
> > ;; b
Hello,
On Tue, 5 Oct 2021, Richard Biener wrote:
> > First notice that this doesn't have an empty latch block to start with
> > (in fact, there is no separate latch block at all), so the loop
> > optimizers haven't been initialized for simple latches at this point.
> > Still, I would say that
On Mon, Oct 4, 2021 at 6:29 PM Michael Matz wrote:
>
> Hello,
>
> On Mon, 4 Oct 2021, Jeff Law wrote:
>
> > And just in case it got lost. Here's the analysis on 960218-1 on visium:
> >
> > We've got this going into ethread:
> >
> > int f (int x)
> > {
> > int D.1420;
> > int a;
> >
> > ;; b
On 10/5/2021 5:22 AM, Richard Biener wrote:
On Mon, Oct 4, 2021 at 6:29 PM Michael Matz wrote:
Hello,
On Mon, 4 Oct 2021, Jeff Law wrote:
And just in case it got lost. Here's the analysis on 960218-1 on visium:
We've got this going into ethread:
int f (int x)
{
int D.1420;
int a;
On 10/5/2021 7:33 AM, Aldy Hernandez wrote:
On Mon, Oct 4, 2021 at 6:29 PM Michael Matz wrote:
Hello,
On Mon, 4 Oct 2021, Jeff Law wrote:
And just in case it got lost. Here's the analysis on 960218-1 on visium:
We've got this going into ethread:
int f (int x)
{
int D.1420;
int a;
On 10/5/2021 7:33 AM, Aldy Hernandez wrote:
OK?
BTW Jeff, this fixes all the regressions you mention except:
1. pr68911.c
The path not being threaded here is 7->10->11->12. It crosses loops
multiple times, so I believe the restriction code is correct.
7, 10, 12 are in loop1.
11 is in loo
On Tue, Oct 5, 2021 at 6:08 PM Jeff Law wrote:
> OK. I think there may still be some concern if the latch is marked as a
> joiner.I think we should always reject those before the loop optimizers
> run as the joiner's clone would introduce a second latch. I think that can
> be handled in
[Here go the bits by Richi, tested on x86-64 Linux, and ongoing tests
on aarch64 and ppc64le.]
There is a lot of fall-out from this patch, as there were many threading
tests that assumed the restrictions introduced by this patch were valid.
Some tests have merely shifted the threading to after loo
On Okt 05 2021, Aldy Hernandez via Gcc-patches wrote:
> From 5abe65668f602d53b8f3dc515508dc4616beb048 Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez
> Date: Tue, 5 Oct 2021 15:03:34 +0200
> Subject: [PATCH] Loosen loop crossing restriction in threader.
>
> Crossing loops is generally discouraged
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bootstrap and break on
the warning, you can see that the uninitaliz
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bootstr
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote:
>
> On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
> -Wmaybe-uninitialized certainly suffers from a high rate of false
> positives (I count 40 open PRs). Even after all this time debugging
> it I still struggle with the code for it bu
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
On 10/6/21 11:03 AM, Aldy Hernandez wrote:
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Okay, thanks. I see what you mean that reducing it to a test case
is challenging. I'll see if I can find some time to distill it to
something useful. U
On 10/6/2021 10:22 AM, Aldy Hernandez via Gcc-patches wrote:
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote:
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
-Wmaybe-uninitialized certainly suffers from a high rate of false
positives (I count 40 open PRs). Even after all this ti
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bo
[Andrew, ranger comment embedded below.]
On 10/7/21 1:06 AM, Jeff Law wrote:
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the
On 10/7/2021 2:15 AM, Aldy Hernandez wrote:
[Andrew, ranger comment embedded below.]
On 10/7/21 1:06 AM, Jeff Law wrote:
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...ever
PING.
Note, that there are no PRs and nothing really dependent on this
patch. This has just been suggested as the right thing to do wrt
loops.
This patch fixes 6 XFAILs in our testsuite and has the added
side-effect of fixing the aarch64 bootstrap problem (though the
problem in the uninit code i
On 10/14/2021 3:25 AM, Aldy Hernandez wrote:
PING.
Note, that there are no PRs and nothing really dependent on this
patch. This has just been suggested as the right thing to do wrt
loops.
This patch fixes 6 XFAILs in our testsuite and has the added
side-effect of fixing the aarch64 bootstra
On 10/6/2021 4:22 AM, Aldy Hernandez wrote:
[Here go the bits by Richi, tested on x86-64 Linux, and ongoing tests
on aarch64 and ppc64le.]
There is a lot of fall-out from this patch, as there were many threading
tests that assumed the restrictions introduced by this patch were valid.
Some tes
On 10/17/21 3:32 AM, Jeff Law wrote:
I think once we reach a consensus on the tests, this will be good to go.
diff --git a/gcc/testsuite/gcc.dg/loop-8.c b/gcc/testsuite/gcc.dg/loop-8.c
index 90ea1c45524..66318fc08dc 100644
--- a/gcc/testsuite/gcc.dg/loop-8.c
+++ b/gcc/testsuite/gcc.dg/loop-
27 matches
Mail list logo
