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

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Thu, 21 May 2009 17:19:53 GMT

          From comp.compilers

Related articles
[15 earlier articles]
Re: behavior-preserving optimization in C, was compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-18)
Re: behavior-preserving optimization in C, was compiler bugs torbenm@pc-003.diku.dk (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs torbenm@pc-003.diku.dk (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs bobduff@shell01.TheWorld.com (Robert A Duff) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs bobduff@shell01.TheWorld.com (Robert A Duff) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs bear@sonic.net (Ray) (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs Jan.Vorbrueggen@thomson.net (=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=) (2009-05-22)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-24)
[6 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Thu, 21 May 2009 17:19:53 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 09-04-072 09-04-086 09-05-010 09-05-022 09-05-028 09-05-038 09-05-039 09-05-050 09-05-055 09-05-065 09-05-069 09-05-072
Keywords: optimize
Posted-Date: 21 May 2009 19:43:05 EDT



"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/


Post a followup to this message

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