Re: gsoc: Loop invariant hoisting

[<don...@is...>]

Charles Zhang writes:
 > You make a good point, but the optimization definitely doesn't apply
 > in this case.

I understand, but this case is not really the point.
There are similar cases, e.g., measuring the time to do
various arithmetic operations, that would be affected.
For instance one of the results recorded in the comment
above the code I sent reports the time taken by code-char,
which if it isn't already recognized as side effect free,
certainly could be.  For that matter my test program
never even used the result, which is another excuse to
optimize out the computation.

And even if my example isn't affected YET, this optimization 
is just one step along a path that seems likely to affect
that example and pretty much all the other similar ones,
which I argue have legitimate uses.

The more general point is that "optimization" is based on a
model of the purpose of the code that is not always correct.
If the purpose of the code is to measure the time it takes to
add two numbers, perhaps of specific types and sizes, when those
types and sizes cannot be determined at compile time, then the
programmer may have to understand the compiler very well in order
to generate a sample test program to answer that question, and 
even with that understanding, generating that test program might
take significant effort.

For the foreseeable future the best solution might be some way
to control the optimizations, perhaps declarations indicating
which individual optimization mechanisms to use or not.  
I can also imagine trying to search the space of optimization 
settings to see what different versions of the compiled code 
can be generated, and running them to measure performance.

If the compiler were smart enough, the programmer could convey
the purpose of the code and the compiler would then know not
to apply certain "optimizations" because they are really not
optimizations for that particular purpose.  But if he could
really explain his intent in some natural way, as opposed to
specifically turning off specific optimizations, then the 
program that tries to understand this more natural description
of intent would probably be able to answer his question in 
some more direct manner.

 > (lambda (n)
 >   (dotimes (i n)
 >     (/ n 0)))
 > 
 > Applying hoisting clearly gives different behavior. The solution,
 > which I am currently implementing, is to also hoist out the
 > condition, so that the hoisted computation runs only 0, or 1 times,

By most definitions of computational "behavior" (which I'm arguing
above are actually inadequate), generating different numbers of
errors, which could potentially involve user interaction, would be
viewed as different behavior.  Do you even have a real definition of
what behaviors are considered equivalent by particular optimizations?