This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
logsofinterest.tar.bz2
Description: BZip2 compressed data
Attachment:
fulllogs.tar.bz2
Description: BZip2 compressed data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |