interesting case of DCE with dataflow.

[Ramana Radhakrishnan]

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


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







-- 
Ramana Radhakrishnan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logsofinterest.tar.bz2
Type: application/x-bzip2
Size: 4406 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20080206/ba568af4/attachment.bz2>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fulllogs.tar.bz2
Type: application/x-bzip2
Size: 54657 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20080206/ba568af4/attachment-0001.bz2>