Re: [tree-ssa] PATCH to gimplify_boolean_expr

[law at redhat dot com]

In message <wvlbrud9xsk.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
 >--=-=-=
 >
 >On Mon, 25 Aug 2003 15:18:08 -0600, law@redhat.com wrote:
 >
 >> In message <wvloeydbny0.fsf@prospero.boston.redhat.com>, Jason Merrill writ
 >es:
 >>  >
 >>  >While testing my patch to always evaluate complex expressions into formal
 >>  >temps, I ran into a new failure on gcc.dg/tree-ssa/20030728-1.c because t
 >he
 >>  >generated gimple code changed from
 >>  >
 >>  >  T1 = (foo == bar);
 >>  >  if (T1)
 >>  >    ...
 >>  >
 >>  >to
 >>  >
 >>  >  T1 = (foo == bar);   // formal temp
 >>  >  T2 = T1;             // variable temp
 >>  >  if (T2)
 >>  >    ...
 >>  >
 >>  >dom provided constant defs of T2 within the branches, but ccp replaced us
 >es
 >>  >of T2 with T1, so we didn't see them.
 >
 >> I'm not sure I follow.  Dumps would probably help me understand what you
 >> mean.
 >
 >.gimple:
 >
 >  F.1 = t1->common.code;
 >  F.2 = (unsigned char)F.1;
 >  F.3 = F.2 == 0;
 >  F.4 = t2 != 0B;
 >  T.5 = F.4;
 >  if (T.5)
 >    {
 >      F.6 = t2->common.code;
 >      F.7 = (unsigned char)F.6;
 >      F.8 = F.7 == 0;
 >      T.5 = F.8;
 >    }
 >  else
 >    {
 >      (void)0
 >    };
 >  F.9 = F.3 ^ T.5;
 >
 >.dom:
 >
 >  F.1_6 = t1_4->common.code;
 >  F.2_7 = (unsigned char)F.1_6;
 >  F.3_8 = F.2_7 == 0;
 >  F.4_10 = t2_9 != 0B;
 >  T.5_11 = F.4_10;
 >  if (F.4_10)
 >    {
 >      # BLOCK 1 (/home/jason/src/ast/gcc/gcc/testsuite/gcc.dg/tree-ssa/200307
 >28-1.c:36).  PRED: 0.  SUCC: 3.
 >      F.6_12 = t2_9->common.code;
 >      F.7_13 = (unsigned char)F.6_12;
 >      F.8_14 = F.7_13 == 0;
 >      T.5_15 = F.8_14;
 >    }
 >  else
 >    {
 >      # BLOCK 2.  PRED: 0.  SUCC: 3.
 >      (void)0
 >    };
 >  
 >  # BLOCK 3 (/home/jason/src/ast/gcc/gcc/testsuite/gcc.dg/tree-ssa/20030728-1
 >.c:36).  PRED: 2 1.  SUCC: 5 4.
 >  #   T.5_1 = PHI <F.8_14(1), F.4_10(2)>;
 >  F.9_16 = F.3_8 ^ T.5_1;
 >
 >In dom, we replaced the conditional use of T.5 with F.4, so we introduce
 >F.4_10==true and F.4_10==false in the arms rather than do the same to T.5.
 >When we re-unify T.5 in block 3, the last value we have for T.5 on the
 >false branch is F.4_10.
 >
 >If we had not done copy prop here, we would have set up the constant values
 >for T.5 instead, and the false one would have flowed into the PHI.
 >
 >Recursing to look up the constant value of F.4_10 in block 2 would also fix
 >this case.
So I went back and removed your change so that I could see this supposed
behavior -- in particular I wanted to see why we didn't propagate the value
zero for F.4_10 in the PHI node.

Unfortunately, after reverting your patch, I get precisely the code I would
expect -- the value of zero is propagated into the PHI node and instead
of a copy we get an initialization to zero for the temporary when we
complete the out-of-ssa pass.

I'm not suggesting you remove your patch -- but that you instead look at
what other local changes you might have which would inhibit constant
propagation.

jeff