On Mon, 15 Sep 2003, Austin Hastings wrote:
> --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > This isn't entirely an easy task, however, since you can't throw away
> > or redo a function/method/sub/whatever that you're already in
> > somewhere in the call-chain, which means any optimizations will
> > have to be either checked at runtime or undoable when code is in
> > the middle of them.
>
> Why is this?
Because there are some assertions that can lead the optimizer to make some
fundamental assumptions, and if those assumptions get violated or
redefined while you're in the middle of executing a function that makes
use of those assumptions, well...
Changing a function from pure to impure, adding an overloaded operator, or
changing the core structure of a class can all result in code that needs
regeneration. That's no big deal for code you haven't executed yet, but if
you have:
a = 1;
b = 12;
foo();
c = a + b;
and a and b are both passive classes, that can get transformed to
a = 1;
b = 12;
foo();
c = 13;
but if foo changes the rules of the game (adding an overloaded + to a or
b's class) then the code in that sub could be incorrect.
You can, of course, stop even potential optimization once the first "I can
change the rules" operation is found, but since even assignment can change
the rules that's where we are right now. We'd like to get better by
optimizing based on what we can see at compile time, but that's a very,
very difficult thing to do.
Dan
