[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Force -O0 flags, inhibit the default -O2 flags

From: Sander Niemeijer
Subject: Re: Force -O0 flags, inhibit the default -O2 flags
Date: Wed, 28 Sep 2005 12:30:35 +0200

Hi All,

On woensdag, sep 28, 2005, at 06:24 Europe/Amsterdam, Ralf Corsepius wrote:

On Tue, 2005-09-27 at 19:38 -0600, Brian wrote:
We have several files which are not able to be optimized, and when our mac mini tries to build the project it chokes up when attempting to do so. It seems incorrect to say that the package developer is the least qualified to
judge compiler flags,
Sorry, but experience tells he is - a developer's view and knowledge are
very limited.

Normally, a developer only knows about the problems he is facing on his
development platforms. Additionally, he might have received a couple of
reports from people using other development platforms. So he might have
some ideas on particular problems on a set of platforms he doesn't have
access to.

 and it also seems to avoid the point. The package
developer should be able to override the autotools, and the user should be
able to override the developer.
The point is: Technically, package developers can override the
autotools, if they really like to, however in most of all such cases
they will not be able to do so, because though developers think they
know what they are doing, they do not actually know it.

From my experience, in 99% of all of such cases, developers trying to
set up CFLAGS/CXXFLAGS end up outsmarting themselves.

For example:
Harald wants to override -O2
a) to work around a compiler bug
b) because the compilation speed/optimization ratio doesn't seem worth

wrt. a):
He would have to detect if the compiler is affected by the bug and how
to work around it.

What he actually knows is that "i386-redhat-gcc-4.0.1-20050731 -O2" as
shipped with "Fedora Core 3 updates as of 20050920" causes a
segmentation fault with a particular code example and that the same
example doesn't segfault with -O2.
He probably doesn't know how the same compiler behaves on other
architectures, nor does he know how other compilers behave on other
hosts/OSes. I.e. he doesn't know the actual origin of the problem and
therefore can't actually provide a work-around. All he can try is to
reduce the likelihood of hitting this issue.

wrt. b)
His decision is based on personal observation on his development
machines and targets, but he has no chance to know about how this
situation is on other platforms.
* Compilation speed on an i386 w/128MB RAM will be completely different
from that on an N-processor SMP sparc-development host w/XX GB RAM
* Compiler memory requirements will be different on different
development haost
* The object sizes for i386 targets will be different from that on
* The "optimal compiler flags" for GCC will be different from that for a
commercial compilers.

So all autoconf and the developer do here, must be somehow
wrong/sub-optimal somewhere. The only person to answer these questions
for a particular host is the "system integrator", i.e. the package's

I agree that the 'system integrator' should have the final say. But my problem is that with the current way automake handles the flags ordering I can't let the user of my package have the final say! At least not in an elegant way that is (the solution I provided in my previous post in the thread is the best I could come up with).

In our case there is just one file that takes an extremely long time to compile if we leave optimization on. We could disable optimization for the whole project, but then the runtime performance of our software would be too slow.

For the users of our software it will probably not be a problem to wait for the compiler to finish, because they will do the compilation only one time (so they can just compile everything using their preferred optimization level). But for our developer team it is important to have both fast compilations _and_ fast runtime performance (for running tests). So what I want is a way to just disable optimization for this single file so the developers of our package (who work on different platforms by the way) don't have to wait unnecessarily long.

As a sidenote, there are other considerations, which take some time to explain, why other solutions such as splitting up this file into smaller files is not a viable solution.

Mind that there are no platform specific tests involved in what I want. All I want is a way to have someone that runs configure be able to say: 'disable optimization for this one file' and 'here are my default CFLAGS' and 'here is my specific flag to disable optimization for a file'. By using such an approach the one that runs configure has full say over everything (no possible faulty enabling/setting of options by the configure script).

I implemented this in by introducing an AC_ARG_VAR variable called DISOPT_FLAG. If the caller to configure does not specify a value to this, then no optimization disabling takes place. But if it is set then the flag that is specified should be used for the compilation of the large file (and this file only). This means that for the large file the compiler options should be '$(CFLAGS) $(DISOPT_FLAG)'.

The problem I now have is that with automake I can't achieve this! There is no way for me to build an automake target where additional compiler options come _after_ the CFLAGS variable (unless I start working around the automake generated rules).

 It is not a matter of qualification, it is a
matter of the chain of command.
It is - It is a matter of personal knowledge.

For example: You seem to know about a particular problem on something
called "mini mac", a platform I have never seen nor used before.
I know about problems on platforms I use and you probably never have
heard about before. We both probably have no idea about what might be
required on other platforms.

I.e. you in your role as "user/system-integrator/packager" will be able
to supply work-arounds for your "mini mac", while I am able to provide
work-arounds for my target platforms.

There is some additional complication in the sense that system-integrators do not always have proper knowledge about the software and therefore may not always know how to properly implement a workaround. For some problems you just need knowledge of both the software _and_ the platform.

My opinion is that a package developer should be free to introduce any workarounds he/she sees fit. The only requirement is that in the end, the user/system-integrator should be free to enable/disable any of these workarounds by providing the right options to the configure script (i.e. no workaround should be enforced on a user).

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]