Re: Mathematics of if-else statements

"Adrian 'Dagurashibanipal' von Bidder" <avbidder@vis.ethz.ch>
10 Sep 2001 23:03:49 -0400

          From comp.compilers

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)
| List of all articles for this month |

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


Post a followup to this message

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