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

torbenm@pc-003.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)
Tue, 19 May 2009 10:49:54 +0200

          From comp.compilers

Related articles
[11 earlier articles]
Re: behavior-preserving optimization in C, was compiler bugs dnovillo@acm.org (Diego Novillo) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs mcintosh@cup.hp.com (Nathaniel McIntosh) (2009-05-16)
Re: behavior-preserving optimization in C, was compiler bugs pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-05-18)
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)
[10 later articles]
| List of all articles for this month |

From: torbenm@pc-003.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)
Newsgroups: comp.compilers
Date: Tue, 19 May 2009 10:49:54 +0200
Organization: Department of Computer Science, University of Copenhagen
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
Keywords: optimize, debug, comment
Posted-Date: 19 May 2009 07:53:20 EDT

Pertti Kellomaki <pertti.kellomaki@tut.fi> writes:


> Anton Ertl wrote:
>> * Do you analyse the program to see if it is actually
>> standard-conformant? If it isn't, do you consider the program to be
>> incorrect, the optimizer to be correct, and do you mark the bug
>> report as invalid? Then you are an apologist. If you don't write
>> optimizers, but think that this attitude is ok, then you are also an
>> apologist.
>
> 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.


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.


Why rely on the programmer to ensure that his code is independent of
evaluation order? A compiler can usually do this more reliably than an
average programmer.


Torben
[The traditional Fortran answer is that the more latitude you give the
compiler, the faster code it can generate. I agree this makes it harder
to write reliable code since you have to defend against all the
transformations it might do. -John]


Post a followup to this message

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