Re: interesting case of DCE with dataflow.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Ramana Radhakrishnan wrote:
> Hi ,
>
> I've been investigating an interesting case with the following
> testcase in my private port. I know this is a slightly theoretical
> case but I believe one that should be handled cleanly.
>
> I haven't yet been able to replicate this on any other port yet whilst
> I have tried ARM, MIPS and m68k.
>
> Consider this case .
>
> void foo (int n, int in[], int res[])
> {
>   int i;
>   for (i=0; i<n;i++)
>     if (in[i])
>       res[i]= 0x1234;
>     else
>       res[i]= 0x1234;
> }
>
> The final code generated appears something like the following.
>
> foo:
>         cmpslt  $c6,$zero,$c1
>         brz     $c6,$link
>         i2cs    $c6,@MID_11(4660)
>         i2c     $c6,@BOT_11(4660)
>         incsi   $c1,-1
> .L5:
>         stw     ($c3[0]),$c6
>         addzi   $c2,$c2,4  -----> This is a redundant add instruction.
>         addzi   $c3,$c3,4
>         brinzdec        $c1,.L5
>         brz     $zero,$link
>
>   
I am completely missing your question.  i do not see any redundancy of
the insn that you say is redundant.  that insn is indexing thru in and
the next insn is indexing thru res. 

Obviously i am missing something.

> Parameters in my port are passed in registers c1, c2 and c3 and hence
> one would expect that the address increment for in[i] with the loop
> would be removed as dead code.  However none of the tree passes remove
> the redundant check as dead code and hence it is left down to the RTL
> passes to cope as best as they can.
>
> After final_cleanup
>
>
> foo (n, in, res)
> {
>   long unsigned int ivtmp.20;
>   long unsigned int ivtmp.18;
>   int i;
>
> <bb 2>:
>   if (n > 0)
>     goto <bb 3>;
>   else
>     goto <bb 8>;
>
> <bb 3>:
>   ivtmp.18 = (long unsigned int) in;
>   ivtmp.20 = (long unsigned int) res;
>   i = 0;
>
> <bb 4>:
>   if (MEM[index: ivtmp.18] != 0)
>     goto <bb 5>;
>   else
>     goto <bb 6>;
>
> <bb 5>:
>   MEM[index: ivtmp.20] = 4660;
>   goto <bb 7>;
>
> <bb 6>:
>   MEM[index: ivtmp.20] = 4660;
>
> <bb 7>:
>   i = i + 1;
>   ivtmp.18 = ivtmp.18 + 4;
>   ivtmp.20 = ivtmp.20 + 4;
>   if (n > i)
>     goto <bb 4>;
>   else
>     goto <bb 8>;
>
> <bb 8>:
>   return;
>
> }
>
>
>
> However the check for if (in[i]) is removed by DCE during peep2 . This
> is insn 43 in the attached logs .
>
>  However insn 58 which is the step instruction for ivtmp.18 which is
> in turn assigned to the parameter "in", does not get removed by DCE .
>
> Shouldn't $c2 become dead after the basic block in which it is
> contained. ? I have tried debugging through this but could not make
> much headway yet. If anyone has any thoughts on this would be quite
> useful to hear it.
>
> I have attached 2 sets of logs - One is with just peephole2 , expand ,
> dce and final_cleanup whilst the other one has everything else
> (fulllogs.tar.bz2)
>
>
>
> cheers
> Ramana
>
>
>
>
>
>
>
>