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

=?ISO-8859-15?Q?Jan_Vorbr=FCggen?= <Jan.Vorbrueggen@thomson.net>
Fri, 22 May 2009 11:11:15 +0200

          From comp.compilers

Related articles
[20 earlier articles]
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)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs ian@airs.com (Ian Lance Taylor) (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-05-29)
[1 later articles]
| List of all articles for this month |

From: =?ISO-8859-15?Q?Jan_Vorbr=FCggen?= <Jan.Vorbrueggen@thomson.net>
Newsgroups: comp.compilers
Date: Fri, 22 May 2009 11:11:15 +0200
Organization: Guest of France Telecom's news reading service
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, comment
Posted-Date: 22 May 2009 07:17:22 EDT

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


Agreed so far.


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


Alternatively (e.g., Fortran), the standard requires (only) that set
of computations to be free of such side-effects as might make the
result indeterministic.


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


While I agree, this is unfortunately academic - most people, and in
particular that subset raised on C/C++ - seem to be unable to accept
(or sometimes even grasp) the concept of the compiler being their
"nanny".


And technically, it isn't easy to do. Even a very restrictive language
such as occam2 made it impossible to use, in a practical program, the
alias and usage checker because of its implementation
deficencies. Yes, that implementation could have been improved, in
particular in its handling of arrays and array slices, and
Fortran-like slice notation would have made its life easier as
well...but doing this without getting in the way of legitmate cases is
very hard. Perhaps the Ada way (be strict in the compiler, but accept
the programmer's explicit instructions to not perform a check here or
there) is the right way to go.


> [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]


See above. I don't think it makes it really that much harder...in
fact, given the pitfalls that are present in other languages that you
can avoid in this way, the bottom line is very likely that your coding
is faster and easier.


Jan
[The particular Fortran problem is that the standard allows the compiler
to make rearrangements that are mathematically equivalent but not
floating point computationally equivalent. -John]


Post a followup to this message

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