Parmenides <mobile.parmenides@xxxxxxxxx> writes: > Now that I think that (x < 0) is more likely, gcc put the instruction > 'movl $-1, -4(%ebp)' immediately after conditional branch instruction > 'je L2'. But, with more conderation about this code, the goal of > improvement in instruction prefetching successfully can not be > achieved similarly. While executing 'je', the CPU is meant to prefetch > the next 'movl'. Even if this prefecthing is sucessful, the following > instruction 'jmp' will cause another failure of prefecthing > definitely. In fact, for a 'if' structure it is seems that the 'jmp' > insturction is inevitable regrardless of how the gcc arrage the code. > Therefore, as a whole, there is no improvement in instruction > prefetching. It is more likely that my opinion is limited somewhere > and the __builtin_expect() should play its role. So, I expect some > explanation about this problem. Your last sentence feels strange in English. You can expect all you like, but all the help you get here comes from unpaid volunteers. In a modern processor an incorrectly predicted conditional branch causes a pipeline bubble. That is not true of an unconditional branch, as the instruction prefetch unit can reliably start fetching at the branch target address. So one goal of the compiler is to ensure that the processor predicts all conditional branches correctly. You are using an Intel/AMD processor; in the absence of other information, Intel/AMD processors predict that forward conditional branches are not taken and predict that backward conditional branches are taken (they also use a hardware branch target prediction buffer which in practice works very well, though of course it only works the second and subsequent times that a conditional branch is seen). The conditional branch in this case is forward, so the processor will predict that it is not taken. That is why gcc arranged for that to be the expected case. Ian
