Re: missing conditional propagation in cprop.c pass

Re: missing conditional propagation in cprop.c pass

[Steven Bosscher]

Hi,

> Though conditional const information "r684 <- 0" is collected by
> find_implicit_sets, the conditional information is recorded as local
> information of bb 97, and it is not recorded in avout of bb 96, so not
> in avin of bb 97 either.

To have the set in avout of bb 96 would be wrong because the set is
only available on the edge from bb 96 to bb 97, but not on the edge
from bb 96 to bb 47.

What should be done about this, is to add the implicit sets to AVIN of
the block that the implicit set is recorded for. You have to do this
after calling lcm.c's compute_available() because the normal
"available expressions" problem in its basic block based form cannot
handle implicit sets. I think something like the patch below
(completely untested, of course ;-) will be necessary to fix this
problem.

If you file a PR with a test case, and assign it to me, I'll have a
closer look and I'll see if I can come up with a proper patch.

Ciao!
Steven



Index: cprop.c
===================================================================
--- cprop.c     (revision 179480)
+++ cprop.c     (working copy)
@@ -641,9 +641,33 @@
 static void
 compute_cprop_data (void)
 {
+  basic_block bb;
+
   compute_local_properties (cprop_absaltered, cprop_pavloc, &set_hash_table);
   compute_available (cprop_pavloc, cprop_absaltered,
                     cprop_avout, cprop_avin);
+
+  /* Merge implicit sets into CPROP_AVIN.  Implicit sets are always
+     available at the head of the basic block they are recorded for.  */
+  FOR_EACH_BB (bb)
+    {
+      if (implicit_sets[bb->index] != NULL_RTX)
+       {
+         rtx implicit_set = implicit_sets[bb->index];
+         int regno = REGNO (SET_DEST (implicit_set));
+         struct expr *set = lookup_set (regno, &set_hash_table);
+
+         /* Find the set that is computed in BB.  */
+         while (set)
+           {
+             if (TEST_BIT (cprop_pavloc[bb->index], set->bitmap_index))
+               break;
+             set = next_set (regno, set);
+           }
+         gcc_assert (set);
+         SET_BIT (cprop_avin[bb->index], set->bitmap_index);
+       }
+    }
 }
 ♀
 /* Copy/constant propagation.  */

Re: missing conditional propagation in cprop.c pass

[Amker.Cheng]

Hi Jeff, Steven,

I have filed a bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50663
Could somebody confirm it?

I am studying this piece of codes and have spent some time on it,
I'm working on a patch and hoping could help on this issue,
Please help me review it later. Thanks.

-- 
Best Regards.

Re: missing conditional propagation in cprop.c pass

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/11 22:43, Amker.Cheng wrote:
>>> 
>>> I believe, the optimization you may be referring to is value
>>> range propagation which does predication of values based on
>>> predicates of conditions. GCC definitely applies VRP at the
>>> tree stage, I am not sure if there is an RTL pass to do the
>>> same.
>> There are also RTL optimizers which perform this kind of
>> constant propagation.  See cprop.c (in older versions of gcc this
>> code was in gcse.c)
>> 
> Hi Jeff, This is exactly what I referred in the first message. 
> Though the cprop.c pass collected the implicit_set information, it
> is recorded as local info of basic block, and cprop only does
> global propagation. The result is such conditional const
> propagation opportunities is missed.
> 
> The whole process in cprop pass is like:
> 
> bb0 : if (x) then bb1 else bb2 end
> 
> 1, implicit_set from the preceding bb0 is tagged as local in bb1; 
> 2, in compute_local_properties, the implicit_set is recorded in
> avloc[bb1]; 3, in compute_cprop_available, the implicit_set is only
> recorded in avout[bb1], not in avin[bb1], which it should be; 4, in
> cprop_insn and find_avail_set, only info recorded in avin[bb1] is
> considered when try to do propagation for bb1;
> 
> Well, I believe it is a small problem, since implicit_set is
> recorded in avout[bb1], The basic block bb1 is the only one get
> missed in propagation.

> 
> Don't know if I described the problem clearly and please comment.
I think you've probably described things fine.    I think at this
point you can either try to fix the problem or file a bug and wait for
someone else to fix it.

The thing to watch out for is these implicit sets are also killed
implicitly.  So you have to make sure the information you record from
the implicit set doesn't escape from the region where the information
is still valid.

jeff
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOifiKAAoJEBRtltQi2kC7+oQH/R7ZnvSUzuzg4jqCR8lh7wZW
UbmsKrH7mTb4QrNlyhPLoioRSOCFIBPbmirmPjpVcgN20328jcXJ+6tB1yaNd5uC
Kw1XjlCn9q3w1gMOhOqiRxgWrTze7gujQK6QdvNH+belI4lPF+AHlCcCcx/qFi7A
n8t3ZOb9EZUtiK5OUlvvNn+PpOfYWbhnrjWlZZIsGcxVry4zmxhrAI5QVNuOHmF6
RDjORrwkTdITs8EbLGYgnNOwDLptjHNUwQBFxjjW2sHxqqJgVwIQj1oeZWCPirHR
CMUAop07HMoW3hgUnF2zq9QDFCjYuLURdqwxD/sMqxmCSES+D9JvAOveP3iiqlw=
=2t39
-----END PGP SIGNATURE-----

Re: missing conditional propagation in cprop.c pass

[Amker.Cheng]

>>
>> I believe, the optimization you may be referring to is value range
>> propagation which does predication of values based on predicates of
>> conditions. GCC definitely applies VRP at the tree stage, I am not
>> sure if there is an RTL pass to do the same.
> There are also RTL optimizers which perform this kind of constant
> propagation.  See cprop.c (in older versions of gcc this code was in
> gcse.c)
>
Hi Jeff,
This is exactly what I referred in the first message.
Though the cprop.c pass collected the implicit_set information, it is recorded
as local info of basic block, and cprop only does global propagation.
The result is such conditional const propagation opportunities is missed.

The whole process in cprop pass is like:

bb0 : if (x)
then
  bb1
else
  bb2
end

1, implicit_set from the preceding bb0 is tagged as local in bb1;
2, in compute_local_properties, the implicit_set is recorded in avloc[bb1];
3, in compute_cprop_available, the implicit_set is only recorded in avout[bb1],
    not in avin[bb1], which it should be;
4, in cprop_insn and find_avail_set, only info recorded in avin[bb1]
is considered
    when try to do propagation for bb1;

Well, I believe it is a small problem, since implicit_set is recorded
in avout[bb1],
The basic block bb1 is the only one get missed in propagation.

Don't know if I described the problem clearly and please comment.

Thanks very much.

-- 
Best Regards.

Re: missing conditional propagation in cprop.c pass

[Amker.Cheng]

>
> Nobody mentioned this so I might be way off but cc doesn't get (minus
> (reg r684) (const_int 0)). It gets the `condition codes` modification as
> a consequence of the subtraction.
>

Hi Paulo,
According to section "comparison operations" in internal:
"The comparison operators may be used to compare the condition codes (cc0)
against zero, as in (eq (cc0) (const_int 0)). Such a construct
actually refers to
the result of the preceding instruction in which the condition codes were set."

and the result of preceding instruction here is the result of the
(compare: r684, 0),
which according to the definition:
"
(compare:m x y)
Represents the result of subtracting y from x for purposes of comparison."

I'm not sure if I've misunderstood any thing and please comment.

Thanks very much.

-- 
Best Regards.

Re: missing conditional propagation in cprop.c pass

[Paulo J. Matos]

"Amker.Cheng" <amker.cheng@gmail.com> writes:
>
> Thanks for replying.
> Sorry if I misunderstood anything below, and please correct me.
>
> insn 882          : cc <- compare (r684, 0)
> jump_insn 883 : if (cc != 0) goto insn 46
> insn 49            : r291 <- r684
> ......
> insn 46
>
> cc contains the result of subtracting 0 from r684;
> control flow goes to insn_49 only if (cc == 0), which implies (r684 == 0).
> Then at insn_49 we have conditional const propagation "r684 <- 0", is it right?
>
> Thanks again.

Nobody mentioned this so I might be way off but cc doesn't get (minus
(reg r684) (const_int 0)). It gets the `condition codes` modification as
a consequence of the subtraction.

-- 
PMatos

Re: missing conditional propagation in cprop.c pass

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/11 09:48, Rahul Kharche wrote:
>> On 09/29/11 17:36, Jeff Law wrote:
>>> On 09/29/11 09:26, Bernd Schmidt wrote:
>>>> ISTR cse.c has some support for this.
>>> cprop.c -- see references to implicit_sets.
>> 
>> cse too: record_jump_equiv.
> 
> Interesting. Are the two approaches subtly different or do they
> apply precisely the same predication?
gcse works globally.  cse works on extended basic blocks.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOhJdTAAoJEBRtltQi2kC7B4MIAKUIBpwl7WtYez16YGBlcHPK
Lav2e4hLmv2lTUloYACIXD172Z4LvrpPZeN++rOt3LIs4q1KRiItF3qnb0Y6Sv+L
FXDHkk8RgMX7lQ2K2X9v3pUNWyxBNk+RAH/6LWvT9MNoCQFkcQNdb0hJoZcTvyww
QILvDXMf5LwypEAWINFjEBIR3UwZfsA1XaOmZ7kvCwudhKSrCZU9Jbud5IBc+Znp
jtxh2rKFyWegejfaS3nXPZF30yLNavKANxtr1DLdLkYt6TotlTexqXgTNXjRyqC5
um4uSMRMPjqyQRhuaCCUfNCMrRwpTld5RbeHHw2y6YH1yma4MzirVmgiu/ITmLQ=
=xvOq
-----END PGP SIGNATURE-----

RE: missing conditional propagation in cprop.c pass

[Rahul Kharche]

> On 09/29/11 17:36, Jeff Law wrote:
> > On 09/29/11 09:26, Bernd Schmidt wrote:
> >> ISTR cse.c has some support for this.
> > cprop.c -- see references to implicit_sets.
> 
> cse too: record_jump_equiv.

Interesting. Are the two approaches subtly different
or do they apply precisely the same predication?

Re: missing conditional propagation in cprop.c pass

[Bernd Schmidt]

On 09/29/11 17:36, Jeff Law wrote:
> On 09/29/11 09:26, Bernd Schmidt wrote:
>> ISTR cse.c has some support for this.
> cprop.c -- see references to implicit_sets.

cse too: record_jump_equiv.


Bernd

Re: missing conditional propagation in cprop.c pass

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/11 08:43, Rahul Kharche wrote:
> 
>> insn 882          : cc <- compare (r684, 0) jump_insn 883 : if
>> (cc != 0) goto insn 46 insn 49            : r291 <- r684 ...... 
>> insn 46
>> 
>> cc contains the result of subtracting 0 from r684; control flow
>> goes to insn_49 only if (cc == 0), which implies (r684 == 0). 
>> Then at insn_49 we have conditional const propagation "r684 <-
>> 0", is it right?
>> 
> 
> I believe, the optimization you may be referring to is value range
> propagation which does predication of values based on predicates of
> conditions. GCC definitely applies VRP at the tree stage, I am not
> sure if there is an RTL pass to do the same.
There are also RTL optimizers which perform this kind of constant
propagation.  See cprop.c (in older versions of gcc this code was in
gcse.c)

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOhJDfAAoJEBRtltQi2kC7f1AH/RQZDQ5PAiTf3rZC9TSGLJhL
zJCTBcmuJmSCyzb9Bk+FLxx9XAfDF3xbv3GZZq4m2qssiG96Qz1UZn28oUx2NShz
a3SAlhucOZGGYxQ482j6ITDIM/y3auuM0obhH1sQtfHyN6A2ndfE4mQ0alhlhIk8
7aaCPQSMtZuJkEeJ41rZ36rEHMSPpgHqx/KhVe4csJ/jBe3/s6PPOCAQav1J5z4p
muJI1CCVRY+XAsKieZYhse8JRF9/iXlKsLHstIJf0HwJRYrSc3JvahEhfNXd+kHk
83Xy8UHkpxn4tPTe3RR2qWdB0yii8WOdX/yH7o8QDZZKwBlhbSjs+wN+iUjbWs0=
=3Bpc
-----END PGP SIGNATURE-----

Re: missing conditional propagation in cprop.c pass

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/11 09:26, Bernd Schmidt wrote:
> On 09/29/11 16:43, Rahul Kharche wrote:
>> 
>>> insn 882          : cc <- compare (r684, 0) jump_insn 883 : if
>>> (cc != 0) goto insn 46 insn 49            : r291 <- r684 
>>> ...... insn 46
>>> 
>>> cc contains the result of subtracting 0 from r684; control flow
>>> goes to insn_49 only if (cc == 0), which implies (r684 == 0). 
>>> Then at insn_49 we have conditional const propagation "r684 <-
>>> 0", is it right?
>>> 
>> 
>> I believe, the optimization you may be referring to is value
>> range propagation which does predication of values based on
>> predicates of conditions. GCC definitely applies VRP at the tree
>> stage, I am not sure if there is an RTL pass to do the same.
> 
> ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOhJCbAAoJEBRtltQi2kC7qdQH/Rd/wTt53jgos8n7LLc5p0eD
dDPCiAR6fHvJqiEBwhgxsQEiifd7NuZR6dW5qPkqhtkJI5HcSpfLqigW+7iNi3oL
Bxx2FHc5Bdtf5QREOcx6XEfVYe6zZitJBkPJ8fuOLz/M8BqJjcZ/JUjs4lnezB9f
RLynyf+JWmPjQHeeKKUp9EmYhozJ8f5kqbKq5S7VF/I2IASWZV02x6mUhaRseEhP
xkFWJOCRKQ3YUP6n+H/eFn6ZMeZ+FvCfVJmy1GLVsb8UsytvPVYoiKO3NageC1rx
99QikyRL2nOE9O4WZn39Mj1PC2YL5lk1WRhDnuyXKcy+GuBnK1HuBrlcnfFady0=
=/NYi
-----END PGP SIGNATURE-----

Re: missing conditional propagation in cprop.c pass

[Bernd Schmidt]

On 09/29/11 16:43, Rahul Kharche wrote:
> 
>> insn 882          : cc <- compare (r684, 0)
>> jump_insn 883 : if (cc != 0) goto insn 46
>> insn 49            : r291 <- r684
>> ......
>> insn 46
>>
>> cc contains the result of subtracting 0 from r684; control flow goes to
>> insn_49 only if (cc == 0), which implies (r684 == 0).
>> Then at insn_49 we have conditional const propagation "r684 <- 0", is it
>> right?
>>
> 
> I believe, the optimization you may be referring to is value range
> propagation which does predication of values based on predicates of
> conditions. GCC definitely applies VRP at the tree stage, I am not
> sure if there is an RTL pass to do the same.

ISTR cse.c has some support for this.


Bernd

RE: missing conditional propagation in cprop.c pass

[Rahul Kharche]

> insn 882          : cc <- compare (r684, 0)
> jump_insn 883 : if (cc != 0) goto insn 46
> insn 49            : r291 <- r684
> ......
> insn 46
> 
> cc contains the result of subtracting 0 from r684; control flow goes to
> insn_49 only if (cc == 0), which implies (r684 == 0).
> Then at insn_49 we have conditional const propagation "r684 <- 0", is it
> right?
> 

I believe, the optimization you may be referring to is value range propagation which does predication of values based on predicates of conditions. GCC definitely applies VRP at the tree stage, I am not sure if there is an RTL pass to do the same.

Re: missing conditional propagation in cprop.c pass

[Amker.Cheng]

> Unless there's something arch specific related to arm, insn 882 is a
> compare, which won't change r684. Why do you think 0 should
> propagated to r291 if r684 is not zero?
>

Thanks for replying.
Sorry if I misunderstood anything below, and please correct me.

insn 882          : cc <- compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49            : r291 <- r684
......
insn 46

cc contains the result of subtracting 0 from r684;
control flow goes to insn_49 only if (cc == 0), which implies (r684 == 0).
Then at insn_49 we have conditional const propagation "r684 <- 0", is it right?

Thanks again.
-- 
Best Regards.

Re: missing conditional propagation in cprop.c pass

[Paulo J. Matos]

"Amker.Cheng" <amker.cheng@gmail.com> writes:

> (insn 882 881 883 96 (set (reg:CC 24 cc)
>         (compare:CC (reg:SI 684 [ default_num_contexts ])
>             (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
>      (nil))
>
>
> The insn49 should be propagated with conditional const from insn882
> and jump_insn883, optimized into "r291<-0" as following code, then let
> pre do redundancy elimination work.

Unless there's something arch specific related to arm, insn 882 is a
compare, which won't change r684. Why do you think 0 should
propagated to r291 if r684 is not zero?

Cheers,
-- 
PMatos

Re: missing conditional propagation in cprop.c pass

[Amker.Cheng]

On Tue, Sep 27, 2011 at 4:19 PM, Amker.Cheng <amker.cheng@gmail.com> wrote:
> Hi,
> I ran into a case and found conditional (const) propagation is
> mishandled in cprop pass.
> With following insn sequence after cprop1 pass:
> ----------------------------------------------------
> (note 878 877 880 96 [bb 96] NOTE_INSN_BASIC_BLOCK)
>
> (insn 882 881 883 96 (set (reg:CC 24 cc)
>        (compare:CC (reg:SI 684 [ default_num_contexts ])
>            (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
>     (nil))
>
> (jump_insn 883 882 886 96 (set (pc)
>        (if_then_else (ne (reg:CC 24 cc)
>                (const_int 0 [0]))
>            (label_ref:SI 905)
>            (pc))) core_main.c:265 223 {*arm_cond_branch}
>     (expr_list:REG_DEAD (reg:CC 24 cc)
>        (expr_list:REG_BR_PROB (const_int 9100 [0x238c])
>            (nil)))
>  -> 905)
>
> (note 886 883 49 97 [bb 97] NOTE_INSN_BASIC_BLOCK)
>
> (insn 49 886 0 97 (set (reg/v:SI 291 [ total_errors ])
>        (reg:SI 684 [ default_num_contexts ])) core_main.c:265 709
> {*thumb2_movsi_insn}
>     (expr_list:REG_DEAD (reg:SI 684 [ default_num_contexts ])
>        (expr_list:REG_EQUAL (const_int 0 [0])
>            (nil))))
> ......
>
> (code_label 905 54 904 47 54 "" [1 uses])
>
> (note 904 905 46 47 [bb 47] NOTE_INSN_BASIC_BLOCK)
>
> (insn 46 904 47 47 (set (reg/v:SI 291 [ total_errors ])
>        (const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
>     (nil))
> ----------------------------------------------------
>
> The insn49 should be propagated with conditional const from insn882
> and jump_insn883, optimized into "r291<-0" as following code, then let
> pre do redundancy elimination work.
> ----------------------------------------------------
> (note 878 877 880 96 [bb 96] NOTE_INSN_BASIC_BLOCK)
>
> (insn 882 881 883 96 (set (reg:CC 24 cc)
>        (compare:CC (reg:SI 684 [ default_num_contexts ])
>            (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
>     (nil))
>
> (jump_insn 883 882 886 96 (set (pc)
>        (if_then_else (ne (reg:CC 24 cc)
>                (const_int 0 [0]))
>            (label_ref:SI 905)
>            (pc))) core_main.c:265 223 {*arm_cond_branch}
>     (expr_list:REG_DEAD (reg:CC 24 cc)
>        (expr_list:REG_BR_PROB (const_int 9100 [0x238c])
>            (nil)))
>  -> 905)
>
> (note 886 883 49 97 [bb 97] NOTE_INSN_BASIC_BLOCK)
>
> (insn 49 886 0 97 (set (reg/v:SI 291 [ total_errors ])
>        (const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
>     (expr_list:REG_DEAD (reg:SI 684 [ default_num_contexts ])
>        (expr_list:REG_EQUAL (const_int 0 [0])
>            (nil))))
> ......
>
> (code_label 905 54 904 47 54 "" [1 uses])
>
> (note 904 905 46 47 [bb 47] NOTE_INSN_BASIC_BLOCK)
>
> (insn 46 904 47 47 (set (reg/v:SI 291 [ total_errors ])
>        (const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
>     (nil))
> ----------------------------------------------------
>
> The problem is function one_cprop_pass does local const/copy
> propagation pass first, then the global pass, which only handles
> global opportunities.
> Though conditional const information "r684 <- 0" is collected by
> find_implicit_sets, the conditional information is recorded as local
> information of bb 97, and it is not recorded in avout of bb 96, so not
> in avin of bb 97 either.
>
> Unfortunately, the global pass only considers potential opportunities
> from avin of each basic block in function cprop_insn and
> find_avail_set.
>
> That's why the conditional propagation opportunity in bb 97 is missed.
>
> I worked a patch to fix this, and wanna hear more suggestions on this topic.
> Is it a bug or I missed something important?
>
> Thanks
>
> BTW, I'm using gcc mainline which configured for arm-none-eabi target.
>

No Interest? Any tips will be great appreciated, thanks.

-- 
Best Regards.

missing conditional propagation in cprop.c pass

[Amker.Cheng]

Hi,
I ran into a case and found conditional (const) propagation is
mishandled in cprop pass.
With following insn sequence after cprop1 pass:
----------------------------------------------------
(note 878 877 880 96 [bb 96] NOTE_INSN_BASIC_BLOCK)

(insn 882 881 883 96 (set (reg:CC 24 cc)
        (compare:CC (reg:SI 684 [ default_num_contexts ])
            (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
     (nil))

(jump_insn 883 882 886 96 (set (pc)
        (if_then_else (ne (reg:CC 24 cc)
                (const_int 0 [0]))
            (label_ref:SI 905)
            (pc))) core_main.c:265 223 {*arm_cond_branch}
     (expr_list:REG_DEAD (reg:CC 24 cc)
        (expr_list:REG_BR_PROB (const_int 9100 [0x238c])
            (nil)))
 -> 905)

(note 886 883 49 97 [bb 97] NOTE_INSN_BASIC_BLOCK)

(insn 49 886 0 97 (set (reg/v:SI 291 [ total_errors ])
        (reg:SI 684 [ default_num_contexts ])) core_main.c:265 709
{*thumb2_movsi_insn}
     (expr_list:REG_DEAD (reg:SI 684 [ default_num_contexts ])
        (expr_list:REG_EQUAL (const_int 0 [0])
            (nil))))
......

(code_label 905 54 904 47 54 "" [1 uses])

(note 904 905 46 47 [bb 47] NOTE_INSN_BASIC_BLOCK)

(insn 46 904 47 47 (set (reg/v:SI 291 [ total_errors ])
        (const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
     (nil))
----------------------------------------------------

The insn49 should be propagated with conditional const from insn882
and jump_insn883, optimized into "r291<-0" as following code, then let
pre do redundancy elimination work.
----------------------------------------------------
(note 878 877 880 96 [bb 96] NOTE_INSN_BASIC_BLOCK)

(insn 882 881 883 96 (set (reg:CC 24 cc)
        (compare:CC (reg:SI 684 [ default_num_contexts ])
            (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
     (nil))

(jump_insn 883 882 886 96 (set (pc)
        (if_then_else (ne (reg:CC 24 cc)
                (const_int 0 [0]))
            (label_ref:SI 905)
            (pc))) core_main.c:265 223 {*arm_cond_branch}
     (expr_list:REG_DEAD (reg:CC 24 cc)
        (expr_list:REG_BR_PROB (const_int 9100 [0x238c])
            (nil)))
 -> 905)

(note 886 883 49 97 [bb 97] NOTE_INSN_BASIC_BLOCK)

(insn 49 886 0 97 (set (reg/v:SI 291 [ total_errors ])
        (const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
     (expr_list:REG_DEAD (reg:SI 684 [ default_num_contexts ])
        (expr_list:REG_EQUAL (const_int 0 [0])
            (nil))))
......

(code_label 905 54 904 47 54 "" [1 uses])

(note 904 905 46 47 [bb 47] NOTE_INSN_BASIC_BLOCK)

(insn 46 904 47 47 (set (reg/v:SI 291 [ total_errors ])
        (const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
     (nil))
----------------------------------------------------

The problem is function one_cprop_pass does local const/copy
propagation pass first, then the global pass, which only handles
global opportunities.
Though conditional const information "r684 <- 0" is collected by
find_implicit_sets, the conditional information is recorded as local
information of bb 97, and it is not recorded in avout of bb 96, so not
in avin of bb 97 either.

Unfortunately, the global pass only considers potential opportunities
from avin of each basic block in function cprop_insn and
find_avail_set.

That's why the conditional propagation opportunity in bb 97 is missed.

I worked a patch to fix this, and wanna hear more suggestions on this topic.
Is it a bug or I missed something important?

Thanks

BTW, I'm using gcc mainline which configured for arm-none-eabi target.