Re: random thought - optimizer

[Joern Rennecke <amylaar at redhat dot com>]

> 
> > My question is, what sort of analysis would it take to recognize this
> > condition?
> 
> Nothing we don't already have (it's just standard unused code elimination 
> stuff) -- but most of our optimizers are severely limited in that they
> assume that a REG is the only useful unit of optimization.  Your variable
> isn't a REG because it lives forever, it's a MEM (and you did remember
> that we committed to code shape and data layout early, so this was
> decided long before optimization time).  Since it's a MEM, we just
> don't do the right thing.
> 
> There are, of course, hacks that we could do to get this right.
> 
> But, the right thing is to rewrite our optimizations to work on
> cleaned up trees.  Then it would Just Work.

Not quite.  You would also have to account for the difference between
static and auto variables.
I.e. arrange for the return value to be used in the exit block,
and add an edge from the exit block to the entry block, where all
function arguments and the stack pointer get assigned with unspecified
values.
Moreover, exit and / or entry block would have to clobber / use unspecified
memory.

Then the function becomes something like:

int initialized = 0;

for(;;)
  {
    /* entry block */

    if (! initialized)
      initialized = 1;

    /* exit block */
  }

However, AFAICS, our current optimizers wouldn't know what to do with this.

One possible chain of transformations would be to detect that the conditional
assignment can be replaced with an OR:

int initialized = 0;

for(;;)
  {
    /* entry block */

    initialized |= 1;

    /* exit block */
  }

And since the or with 1 is idempotent, and executed at least once, we can
sink it:

int initialized = 0;

for(;;)
  {
    /* entry block */

    /* exit block */

  }
initialized |= 1;

And now, when we transform back to an ordinary flow graph that starts with
the entry block and ends with the exit block, the function is empty.