This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimization of conditional access to globals: thread-unsafe?

Joe Buck wrote:
From: "Dave Korn" <>
Better write your own compiler then.

On Sun, Oct 28, 2007 at 06:34:01PM -0700, David Miller wrote:
If this becomes the common attitude of GCC developers, you can pretty
much guarentee this will drive people to work on LLVM and other
alternative compiler code bases.

The primary job of GCC is to serve as the compiler for the GNU/Linux system. This trumps strict, anal-retentive standards conformance, though ideally it should come as close as possible to achieving both.

Well actually I think "strict anal-retentive standards conformance" is
never trumped. The compiler MUST be standards conforming. However, this
issue has nothing to do with conforming or not conforming to the standard in the sense that no one is suggesting non-conformance.

The issue is whether to take optional advantage of freedoms granted
by the standard in performing optimizations, and that's another matter
entirely. Optimization is not a matter of conformance (the standard
allows but does not require optimization). In considering an optimization we must meet two criteria

a) the standard allows the optimization (or rather does not forbid it)

b) the optimization is pragmatically useful (the gains exceed the losses). The fact that an optimization is allowed by the standard is
NOT of itself an argument in favor of doing the optimization

There are cases where we need to depart from the standard somewhat,
because it doesn't reflect existing practice.  Aggressively optimizing
on the basis that overflow of ints is undefined would, for example,
break GCC itself, as well as many Unix and Linux programs.  This makes
the job more difficult.

It is not "depart[ing] from the standard" to decline to "aggressively optimize on the basis that overflow of ints is undefined". The standard permits this, but does not require it, or even suggest it, it merely enables it, so that we can consider whether it is a good idea.

Unfortunately, too many GCC developers believed what they were told in
their university compiler courses: that the language standard is the
contract.  But that is only part of the story.

The language standard is a contract, but there is a big difference between a required performance element of a contract and something
that is allowed. If you get a mortgage from a bank, it is unlikely
that there is anything in this contract that forbids you from
painting the outside of your house purple with yellow stripes, but
that does not mean it is a good idea to do so.

What I think is a possible fault among *some* GCC developers, certainly
not all, is the notion that if an optimization is allowed, and if it
improves performance of at least some programs, then it is automatically
a good idea to do the optimization.

A similar situation arises in Ada with the question of whether the
compiler should assume that subtypes are in range, e.g. if you say

X : Integer range 1 .. 10;

is the compiler allowed to assume X is in range (answer yes), should
it do so? (answer, many including me at AdaCore thing the answer is
a thundering no, but others at AdaCore are equally adamant that the
answer should be yes, so this is unresolved, currently the compiler
does make this assumption).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]