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
>
>
>
>
>
>
>
>
