Re: Optimizing nested if statements?

Saverio Perugini <sperugin@csgrad.cs.vt.edu>
25 Jan 2003 01:12:56 -0500

          From comp.compilers

Related articles
Optimizing nested if statements? sperugin@csgrad.cs.vt.edu (Saverio Perugini) (2003-01-17)
Re: Optimizing nested if statements? christian.bau@cbau.freeserve.co.uk (Christian Bau) (2003-01-21)
Re: Optimizing nested if statements? terryg@qwest.net (Terry Greyzck) (2003-01-21)
Re: Optimizing nested if statements? vbdis@aol.com (2003-01-21)
Re: Optimizing nested if statements? sperugin@csgrad.cs.vt.edu (Saverio Perugini) (2003-01-25)
Re: Optimizing nested if statements? Martin.Ward@durham.ac.uk (2003-01-26)
Re: Optimizing nested if statements? sperugin@csgrad.cs.vt.edu (Saverio Perugini) (2003-02-06)
| List of all articles for this month |
From: Saverio Perugini <sperugin@csgrad.cs.vt.edu>
Newsgroups: comp.compilers
Date: 25 Jan 2003 01:12:56 -0500
Organization: Virginia Tech, Blacksburg, Virginia, USA
References: 03-01-092 03-01-116
Keywords: optimize, question
Posted-Date: 25 Jan 2003 01:12:56 EST

Hello,


By now it is agreed by all parties involved that I bungled my example.
I apologize for that.


Please allow me to correct it.


Re-consider the following code:


if (a) {
      if (b) {
            if (c) {
                  ...
            } else if (d) {
                                ...
                }
      }
} else if (e) {
                    ...
    }


This code is semantically equivalent to
the following piece of code.


if (a) {
      if (b && c) {
            ...
      } else if (b && d) {
                          ...
          }
} else if (e) {
                    ...
    }


The title of this thread was phrased incorrected. I am not interested
in optimizing anything. Everybody has contributed correct information
with respect to compilers to this post. I am not however interested
in object code, side-effects, short-circuit evaluation, run-time
errors, etc. I apologize for conveying that impression in my initial
mail.


I am using these code fragments only as data representations. I never
intend to compile or run them. I am simply using the control
structure to model data. In my data, I want to perform a
transformation which corresponds to the syntax-to-syntax
transformation which I illustrate above.


The code transformation entails consolidating consecutive single
variable conditional expressions which do not contain else clauses
(e.g., the if (b) conditional above) with each of their nested child
conditionals.


Therefore, I am looking for a syntax-to-syntax transformation. In
other words, I want an actual semantically equivalent, yet
syntactically different program.


More than this, I am really interested in whether there is a
theoretical programmatic operation (e.g., partial evaluation, program
slicing, or unfold/fold) which can be associated with this type of
transformation. Furthermore, I am not advocating that this syntactic
transformation is the way the data transformation should be
implemented. I am really just looking for a metaphor or association
to a theoretical operator.


>In any case, there are tools, such as our DMS software
>reengineering toolkit, that can do this easily,
>and without making the paper and pencil mistake.
>See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.
>This applies source-to-source transformations to the text.


>A transform for this might look like:
>
> " if (\e1) { if (\e2) \b else \s } "
> -->
> " if (\e1 && \e2) \b
> else if (!\e1 && !e2) \s"
> if no_side_effects(e1) & no_side_effects(e2).


>DMS can carry out much more interesting transformations
>than this, and has been used to translation
>from one language to another, moving hundreds
>of thousands of lines reliably.


Sounds interesting. I have checked out the webpage. Is DMS freely
available for academic use? The webpage only seems to state `Large
discount for University research groups.'


Thank You and Best Regards,
Saverio Perugini


Post a followup to this message

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