Whilst investigating a missed optimization oppurtunity in comparison to gcc 3.4 I came across 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]= 0x9876; } The basic block structure generated is as follows foo (n, in, res) { unsigned int ivtmp.19; int i; <bb 2>: if (n > 0) goto <bb 3>; else goto <bb 8>; <bb 3>: i = 0; ivtmp.19 = 0; <bb 4>: if (MEM[base: in, index: ivtmp.19] != 0) goto <bb 5>; else goto <bb 6>; <bb 5>: MEM[base: res, index: ivtmp.19] = 4660; goto <bb 7>; <bb 6>: MEM[base: res, index: ivtmp.19] = 39030; <bb 7>: i = i + 1; ivtmp.19 = ivtmp.19 + 4; if (n > i) goto <bb 4>; else goto <bb 8>; <bb 8>: return; } If you notice ivtmp.19 can be used for post-increment based addressing modes. Note that GCC 3.4 did not have another basic block for the else case, the basic block for the else case got merged with the tail block of the loop and hence auto-inc could get generated in the else case and not in the if side of things. Can be reproduced with today's head of 4.3.0 -- Summary: Missed autoincrement oppurtunities thanks to a different basic block structure. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana dot radhakrishnan at celunite dot com GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849