Subject: Re: UPDATE: -pipe didn't boost up compile speed :-(
To: None <email@example.com>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 07/07/2002 18:53:31
Date: Sat, 6 Jul 2002 12:12:11 +0900
From: Bang Jun-Young <firstname.lastname@example.org>
| Now, it is clear that -pipe doesn't boost up kernel compile on a
| slow machine. You can benefit from it with a fast machine with enough
Regardless of the benefits, or not, of this kind of optimisation, I'd
like to request that it not be made the default.
It is trivially easy for anyone building kernels, or whole systems,
to enable whatever optimisations work best for them - but it is usually
much harder for an optimisation turned on by default to trivially be
turned off again.
As best I can tell, there is no "-nopipe" option, or anything equivalent,
the only way to disable the option, is not to specify it. So, if you
turn it on by default, people need to figure out what to go and fiddle
to make it go away. There's no simple "CFLAGS+=" they can be told to
do, and a "CFLAGS=" may be disabling other flags that should be set.
If the gcc people felt that having -pipe turned on by default was a
reasonable choice, then I suspect they'd do that, and provide an option
to reverse it at the same time. Until that happens, let's just leave
things as they are.
I know that for a lot of people reading this, making the build go as fast
as possible is important - but that's not true for everyone. Personally,
I almost never care how long it takes, more important to me is that the
effect on the system while the build is happening is minimised to the
greatest extent possible (as in "nice ./build.sh ..."). I tend to have
plenty of other work to do, and much prefer the system to keep doing my
work, and just run the build, as slow as it likes, in the background.