------- Comment #11 from rguenther at suse dot de 2010-02-13 12:07 -------
Subject: Re: [4.5 Regression] gcc.target/mips/octeon-bbit-2.c
failing for -mabi=64
On Sat, 13 Feb 2010, steven at gcc dot gnu dot org wrote:
>
>
> ------- Comment #10 from steven at gcc dot gnu dot org 2010-02-13 11:39
> -------
> In the test case of comment #2, the history of the funny PHIs is really odd.
> At
> -O2 we end with this in the .optimized dump:
>
> <bb 3>:
> # i_1 = PHI <0(2)>
> # s_11 = PHI <0(2)>
>
> <bb 4>:
> # i_12 = PHI <i_1(3), i_7(4)>
> # s_13 = PHI <s_11(3), s_6(4)>
>
>
> But the history of the phi of i_12 looks like this:
>
> t.c.120t.reassoc2: # i_12 = PHI <i_7(3), 0(2)>
> t.c.121t.vrp2: # i_12 = PHI <i_2(3), i_7(7)>
> t.c.121t.vrp2: # i_12 = PHI <0(3), i_7(4)>
> t.c.122t.dom2: # i_12 = PHI <0(3), i_7(4)>
> t.c.123t.phicprop2: # i_12 = PHI <0(2), i_7(3)>
> t.c.124t.cddce2: # i_12 = PHI <i_1(3), i_7(6)>
>
> Somehow we have re-introduced the special PHI "# i_1 = PHI <0(2)>" in the
> .cddce2 pass. The reason is that we created a loop pre-header.
Yep. I wonder if cfgcloop should just not do that, and of course
I wonder why cfgcleanup doesn't get rid of single-arg PHIs (well,
probably to not break loop-closed SSA form).
Btw, the following should avoid almost all constant propagations
into PHIs (well, I guess DOM needs fixing as well)
Index: tree-ssa-propagate.c
===================================================================
--- tree-ssa-propagate.c (revision 156666)
+++ tree-ssa-propagate.c (working copy)
@@ -924,7 +924,9 @@ replace_phi_args_in (gimple phi, prop_va
{
tree val = prop_value[SSA_NAME_VERSION (arg)].value;
- if (val && val != arg && may_propagate_copy (arg, val))
+ if (val && val != arg
+ && TREE_CODE (val) == SSA_NAME
+ && may_propagate_copy (arg, val))
{
if (TREE_CODE (val) != SSA_NAME)
prop_stats.num_const_prop++;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
