Re: Compiler loop optimizations

Christian Sturz <linuxkaffee@gmx.net>
5 Jan 2007 05:49:46 -0500

          From comp.compilers

Related articles
Compiler loop optimizations linuxkaffee@gmx.net (Christian Sturz) (2006-12-29)
Re: Compiler loop optimizations emailamit@gmail.com (Amit Gupta) (2006-12-31)
Re: Compiler loop optimizations robert.hundt@gmail.com (Robert H) (2007-01-01)
Re: Compiler loop optimizations robert.hundt@gmail.com (Robert H) (2007-01-01)
Re: Compiler loop optimizations torbenm@app-0.diku.dk (2007-01-05)
Re: Compiler loop optimizations linuxkaffee@gmx.net (Christian Sturz) (2007-01-05)
Re: Compiler loop optimizations emailamit@gmail.com (Amit Gupta) (2007-01-07)
Compiler loop optimizations Heiko.Falk@udo.edu (Heiko Falk) (2007-01-10)
Re: Compiler loop optimizations hebisch@math.uni.wroc.pl (Waldek Hebisch) (2007-01-11)
Compiler Loop Optimizations plfriko@yahoo.de (Tim Frink) (2008-02-28)
| List of all articles for this month |

From: Christian Sturz <linuxkaffee@gmx.net>
Newsgroups: comp.compilers
Date: 5 Jan 2007 05:49:46 -0500
Organization: Compilers Central
References: 06-12-109 06-12-115
Keywords: optimize
Posted-Date: 05 Jan 2007 05:49:46 EST

On Sun, 31 Dec 2006 09:25:37 -0500, Amit Gupta wrote:


> NOW, you don't really need to worry if gcc/CC can optimize this
> particular program. The processor branch prediction unit will be able
> to take care of it.


[...]


> Similarily, for f100, (i==15) will result in only two stall(before and
> after) when branch prediction unit goes wrong. Over 100 iterations
> though, the execution time spent is minimal (also depends if Block1
> changes variables used in the loop).


Thank you very much for your very helpful answers. I don't fully
understand your arguments concerning the conditional statement. There
are two issues that must be taken into account. On the one hand, the
branch prediction. I agree to that what you wrote. The prediction
remains the same for most of the loop iterations, so the number of
conditional pipeline hazards is reduced to one or two. So, in this
case the hardware takes care to optimize the program execution.


On the other hand, the executed code. When the functions "foo10" and
"foo100" contain the conditional expression "(i==15)", this result in a
conditional jump instruction that has to be evaluated for each loop
iteration. This means, for "foo10" there are 10 more instruction, for
"foo100" 100 conditional instructions that must be executed compared to
an optimized version that eliminates "(i==15)". So, this yields a longer
program execution. Thus, I was of the opinion that the elimination of this
redundant conditional expression reduces the number of executed
instruction and so substantially decreases the program execution time.


That's why I think that one should worry if the compiler optimizes this
particular code. Or are my assumptions wrong?


Best regards,
Christian



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.