Related articles |
---|
Mathematics of if-else statements bora@nope.com (Bora Eryilmaz) (2001-09-05) |
Re: Mathematics of if-else statements avbidder@vis.ethz.ch (Adrian 'Dagurashibanipal' von Bidder) (2001-09-10) |
Re: Mathematics of if-else statements old_dnepr@yahoo.com (2001-09-10) |
Re: Mathematics of if-else statements joachim_d@gmx.de (Joachim Durchholz) (2001-09-11) |
Re:Mathematics of if-else statements dsha@tepkom.ru (Dmitry Shaporenkov) (2001-09-11) |
From: | "Adrian 'Dagurashibanipal' von Bidder" <avbidder@vis.ethz.ch> |
Newsgroups: | comp.compilers |
Date: | 10 Sep 2001 23:03:49 -0400 |
Organization: | Compilers Central |
References: | 01-09-020 |
Keywords: | optimize |
Posted-Date: | 10 Sep 2001 23:03:49 EDT |
Behold! For Bora Eryilmaz declaimed:
> Are there any mathematical/logical approaches to analyze nested if-else
> statements in order to simplify or optimize them, or to understand the
> flow of successive tests. For example, if I have
[sa'snip]
Probably the best way to optimize jumps (applies to conditions as well
as to loops, but I'd imagine the latter would be more complicated)
would be using profiling information.
If you know which branch is taken how often (sometimes you know it
even while programming) you then optimize so that the rarely taken
branch is on the slower path (depends on your architecture, perhaps an
unconditional taken branch may be faster than a conditional one not
taken or vice versa. You'd know quite a lot about the pipeline
architecture for this kind of optimizations).
One optimization which probably applies to almost any architecture (it
saves one jump) would be to transform:
...
if (foo)
bar
return
to
...
if (!foo)
return
bar
But again, depending on how big the penalty for taken/not taken branches
is, the one saved (unconditional) is not much.
-- vbi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.