GCC as enabled with -freorder-blocks and a optimization level larger 1 will reorder instructions at a block level. This optimization is mainly to compress correlated code to provide a optimized cache aware memory layout. Because of some Linux kernel hacking I forced to get the details when and where GCC's optimizations kicks in. The most effective way for userland programs without branch-taken-knowledge is through profile guided optimization nowadays. But this is not possible in every setup (lack of realistic input data, ...). Another way are GCC's builtin expect statement - but this required exact knowledge of data paths and realistic input data. The next two snippets show how GCC reorder a simple if-else statement (just for demonstration):
4004c0: 83 ff 01 cmp $0x1,%edi 4004c3: 7f 04 jg 4004c9 <process+0x9> 4004c5: 8d 47 01 lea 0x1(%rdi),%eax 4004c8: c3 retq 4004c9: 8d 47 02 lea 0x2(%rdi),%eax 4004cc: c3 retq
4004c0: 83 ff 01 cmp $0x1,%edi 4004c3: 7e 04 jle 4004c9 <process+0x9> 4004c5: 8d 47 02 lea 0x2(%rdi),%eax 4004c8: c3 retq 4004c9: 8d 47 01 lea 0x1(%rdi),%eax 4004cc: c3 retq
The fascinating question is what are the limits of this optimization. What are the influences of nested statements? Are there any thresholds not to reorder blocks? I just prepared some code generation script to analyze this characteristic. But now do some tests and write an analyzer script too.