+ gcc mailing list
-- Forwarded message -
From: Claudiu Zissulescu Ianculescu
Date: Tue, Dec 20, 2022 at 2:31 PM
Subject: Re: Possible regression in DF analysis
To: Jeff Law
Hi Jeff,
> Or is that the core of the problem -- that life analysis is inaccurate
> or unava
On 12/8/22 04:51, Claudiu Zissulescu Ianculescu via Gcc wrote:
Hi Eric,
The problem shows in loop-doloop.c when I introduce a loop end pattern
that replaces the first jump instruction (JUMP_INSN 15) with a pattern
that clobbers CC reg. However, the DF doesn't look like it works as
the doloop s
On Wed, Dec 14, 2022 at 12:30 PM Claudiu Zissulescu Ianculescu
wrote:
>
> Hi Richard,
>
> Sorry for my misunderstanding. I am calling the df_analyze() instead
> of df_analyze1() at the end. Shouldn't df_analyze take care and
> compute the correct postorder (df-core.cc:1273) ?
The point of df_ana
Hi Richard,
Sorry for my misunderstanding. I am calling the df_analyze() instead
of df_analyze1() at the end. Shouldn't df_analyze take care and
compute the correct postorder (df-core.cc:1273) ?
Thank you,
Claudiu
On Wed, Dec 14, 2022 at 1:06 PM Richard Biener
wrote:
>
> On Wed, Dec 14, 2022 a
On Wed, Dec 14, 2022 at 11:37 AM Claudiu Zissulescu Ianculescu
wrote:
>
> I have update the fix to this one:
>
> diff --git a/gcc/df-core.cc b/gcc/df-core.cc
> index a901b84878f..cc6383990a1 100644
> --- a/gcc/df-core.cc
> +++ b/gcc/df-core.cc
> @@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *
I have update the fix to this one:
diff --git a/gcc/df-core.cc b/gcc/df-core.cc
index a901b84878f..cc6383990a1 100644
--- a/gcc/df-core.cc
+++ b/gcc/df-core.cc
@@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop)
df_set_blocks (blocks);
BITMAP_FREE (blocks);
- df_analyze_1 ();
+ /* I
>
> Maybe you want to iterate over the loops exit edges and include their
> destination block instead?
>
This is better approach, let me try it and I will be back to you.
Thanks,
Claudiu
> Am 13.12.2022 um 17:54 schrieb Claudiu Zissulescu Ianculescu via Gcc
> :
>
> UPDATE:
> The df_analyze_loop is calling the df_set_blocks. Thus, the analysis
> behaves as if the function only contains those blocks and any edges
> that occur directly between the blocks in the set (see df-core.
UPDATE:
The df_analyze_loop is calling the df_set_blocks. Thus, the analysis
behaves as if the function only contains those blocks and any edges
that occur directly between the blocks in the set (see df-core.cc).
This said, the loop-doloop behaves faulty at loop-doloop.cc:772 as the
df_get_lives_ou
It looks like that. The df_analyze_loop is only looking at the loop
BBs, and it is not clear for me if df_analyze_loop is required to have
all the df_live_outs correctly computed or not. Do you know if it is
true?
If the df_analyze_loop is not supposed to compute all the df_live_outs
correctly, th
> The problem shows in loop-doloop.c when I introduce a loop end pattern
> that replaces the first jump instruction (JUMP_INSN 15) with a pattern
> that clobbers CC reg. However, the DF doesn't look like it works as
> the doloop step cannot find the CC reg alive. Please see
> loop-doloop.c:766. Hen
Hi Eric,
The problem shows in loop-doloop.c when I introduce a loop end pattern
that replaces the first jump instruction (JUMP_INSN 15) with a pattern
that clobbers CC reg. However, the DF doesn't look like it works as
the doloop step cannot find the CC reg alive. Please see
loop-doloop.c:766. Henc
> However, after this optimization I get the CC reg being dead after
> JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
> from fwprop1:
>
> (insn 14 11 15 3 (set (reg:CC 66 cc)
> (compare:CC (reg/v:SI 98 [ bytes ])
> (const_int 8 [0x8]))) "bad_cc.c":11:8 406
Hi,
I've stumbled over a potential issue related to Dataflow analysis,
and maybe you can help me with it. It can be reproduced for AARCH64
but other architectures are affected as well.
I have the next snip before CSE1 pass:
(insn 14 11 15 3 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [
14 matches
Mail list logo
