Re: behavior-preserving optimization in C, was compiler bugs

"Christopher Glaeser" <cdg@nullstone.com> writes:
>> If you want to implement an optimization that needs initialized local
>> arrays to preserve the behaviour, it's certainly worth considering.
>> Or you may find a different way to preserve the behaviour.
>
>Initialize to what?


It does not matter for preserving behaviour, as long as the
initialization is the same with and without optimization.


Of course, if you are already initializing, you might just as well
initialize to a defined value that also survives, e.g., program
changes. Initializing to 0 can be relatively cheap (e.g., on the PPC
architecture with the dcbz instruction). It can actually be cheaper
to initialize an array by using such cache-manipulation instructions
first and storing there only afterwards (but it depends on the
concrete usage whether this is cheaper or not).


>Suppose you are responsible for maintaining a C compiler and you
>receive a defect report with a program that works fine without
>optimization but generates a divide by zero exception with
>optimization. You analyze the program and determine that the divide
>by zero is in a function that references an uninitialized local array
>element. Without optimization, the array element has a value of 1
>due to the more-or-less random state of the stack on entry to the
>function. With optimization, changes to register and stack
>assignments cause changes to the state of the stack on entry to the
>function, and now the uninitialized local array element has the value
>0, which causes the divide by zero exception. How would you respond
>to this defect report?


I would think about how to fix the bug in the optimizer. Within a few
minutes I came up with the following approaches:


* Initialize the array (possibly on-demand as discussed in an earlier
    message).


* Make sure that the stack state left by earlier uses of the stack is
    the same with and without optimization. This could be done by
    performing stores that might otherwise seem superfluous, but it's
    probably cheaper to just clear the stuff that might have a different
    value on exit from the function (and on architectures where the
    return address is read directly from the stack on returning, clear
    the return address after returning, if necessary).


* Disable the optimizations that cause the differences in the stack
    contents.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

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