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

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Thu, 21 May 2009 18:03:55 GMT

          From comp.compilers

Related articles
[16 earlier articles]
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)
Re: behavior-preserving optimization in C, was compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-05-25)
[5 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 18:03:55 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-075 09-05-079
Keywords: optimize, debug
Posted-Date: 21 May 2009 19:43:32 EDT

torbenm@pc-003.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen) writes:
>Pertti Kellomaki <pertti.kellomaki@tut.fi> writes:
>> Or a formalist. For example, the Scheme specification does not specify
>> the order in which function arguments are evaluated. As far as I am
>> concerned, an implementation would be free to evaluate arguments left
>> to right on weekdays and right to left on weekends. If my code relies
>> on something that is not explicitly promised by the language, that's
>> my fault, not the compiler's.


If you are talking about your own code, it's certainly your right to
think this way. But if you write an optimizer, it's your business to
optimize the working program, not to break it.


>I agree. But I also think that it is a problem for a language to
>leave visible behaviour unspecified, except for indirectly visible
>behaviour such as resource use. So, you should only leave order of
>evaluation unspecified if the order can not directly influence the
>result of the program, i.e., when there are no side effects. This
>does not mean that the language shold be free of side effects, but
>only that the language definition guarantees that side-effecting
>computations are in the same standardized order regardless of which
>compiler, optimisation level or target machine you use.


Yes, that's a good idea. But if the language standard does not do it,
at least the compiler should do it.


The funny thing is that such weaknesses in language standards
typically come around because two different implementations do it
differently. And since the implementors know that the existing
programs for their compilers rely on the order, they won't change the
way their compilers work, and as a compromise this particular aspect
is not standardized. Then a few years down the road the apologists
(or, if you want, formalists, or language lawyers) say that programs
that rely on the order like the ones that were the reason for the
weakness are not just non-standard, but "incorrect" and ignore any
bugs in the optimizer that occur in these programs. (I don't know if
that's what happened in Scheme).


- 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.