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) |
From: | "Amit Gupta" <emailamit@gmail.com> |
Newsgroups: | comp.compilers |
Date: | 7 Jan 2007 08:31:06 -0500 |
Organization: | Compilers Central |
References: | 06-12-10906-12-115 07-01-015 |
Keywords: | optimize, architecture |
Posted-Date: | 07 Jan 2007 08:31:06 EST |
Christian Sturz wrote:
> On Sun, 31 Dec 2006 09:25:37 -0500, Amit Gupta wrote:
>
[..]
> 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)".
You are correct. If you are counting the number of instructions
executed by the compiler without any stall/jump, then the suggested
transformation will reduce the count.
>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.
As an engineer, I don't think your last statement would always hold
ground ("substantially decrease program execution time"). You get
speed-up by minimizing stalls and jump instruction. Executing few
instructions on a GHz-processor, when there is no stall, is not that
big a deal. In your case, the branch prediction unit is avoiding stall,
by speculating earlier and winning 99% of the time.
However, as mentioned by other reviewers here, there could be other
benefits related to better pipelining, register allocation, reduced
code size by your transformation.
In summary, your point to optimize unreachable code, as a fundamental
way of reducing instruction count is absolutely correct.
-Amit
> That's why I think that one should worry if the compiler optimizes this
> particular code. Or are my assumptions wrong?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.