There was another interp about optimization, I think it was a FORTRAN
77 one. It was about what kind of optimization was allowed in a
logical expression with lots of .AND., .NOT., .OR., etc. I don't
remember the details, but it was more or less that someone had
written a simple test expression, like IF(A .AND. B) ...
and a much more complicated one with lots of operators, operands,
and parens. He saw that the compiler generated the same code for
both expressions. The question was "Can a compiler use things like
De Morgan's rule, etc. to reduce complicated logical expressions
into simple ones?" I recall the answer to be something like
"Who knows? The standard does NOT specify code sequences for
expression evaluation. There is no way to look at the "generated
code" (whatever that is) and tell if the compiler has done something
non standard." In effect, optimizations which are not detectable
with something like PRINT statements are OK.
Dick Hendrickson
>
> James Giles wrote:
> >
> > Walt Brainerd <[log in to unmask]> wrote:
> >
> > >James Giles wrote:
> > >
> > >> My own bias is that the only transformations that should be allowed
> > >> are either those which entirely preserve the semantics of the original
> > >> program or those explicitly permitted by the standard (mathematically
> > >> equivalent transformations within a single expression that don't invade
> > >> the integrity of parenthesis). This is because I really would like to
> > >> move toward that ideal world where optimization was entirely a
> > >> pragmatic issue.
> > >
> > >I don't understand this: whether is "pragmatic" or not, if the standard
> > >says you can only do what you propose, how can it do otherwise?
> > >
> > >Where will it all end? This would prevent "inlining" of procedures
> > >because (unless some other strange things have been done to the
> > >standard), I don't think there is any place that allows it. In fact,
> > >there are explicit words to the effect that a CALL statement is executed
> > >by executing the subroutine.
> >
> > Yes, but it doesn't specify how the subroutine is to be executed.
> > Executing an inline copy is perfectly reasonable. In fact, there's
> > nothing in the standard that prohibits inlining *all* procedure calls
> > and using an environment which doesn't even possess "return jumps"
> > or any other such support. Such a transformation would be entirely
> > concerned with the pragmatics of the program since it would
> > leave the semantics completely unchanged.
> >
> > --
> > J. Giles
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|