Re: Compiler loop optimizations

"Amit Gupta" <>
7 Jan 2007 08:31:06 -0500

          From comp.compilers

Related articles
Compiler loop optimizations (Christian Sturz) (2006-12-29)
Re: Compiler loop optimizations (Amit Gupta) (2006-12-31)
Re: Compiler loop optimizations (Robert H) (2007-01-01)
Re: Compiler loop optimizations (Robert H) (2007-01-01)
Re: Compiler loop optimizations (2007-01-05)
Re: Compiler loop optimizations (Christian Sturz) (2007-01-05)
Re: Compiler loop optimizations (Amit Gupta) (2007-01-07)
Compiler loop optimizations (Heiko Falk) (2007-01-10)
Re: Compiler loop optimizations (Waldek Hebisch) (2007-01-11)
Compiler Loop Optimizations (Tim Frink) (2008-02-28)
| List of all articles for this month |

From: "Amit Gupta" <>
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.


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

Post a followup to this message

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