On Fri, Apr 07, 2006 at 03:46:42AM -0700, J?rgen Keil wrote:

> The recently released on-20060404 release has added "gcc" shadow
> compilation, and it seems a lot (all?) files are now compiled four times
> (debug i386 & amd64 using Sun cc;  + debug i386 & amd64 using gcc).

Not quite.  Most C and C++ source files are now compiled twice for
each invocation of $(CC) or $(CCC).  For most libraries and kernel
sources applicable to x86, that does indeed mean they will be compiled
4 times.  Some kernel files are compiled many more times on SPARC for
per-platform kernels and modules.

> Because of the extra gcc compiler invocations, nighty build time seems to 
> have increased
> by 30 - 50% (unless you set the environment variable CW_NO_SHADOW, do disable
> gcc shadow compilation; see "man -M /opt/onbld/man cw").

It depends greatly on the type of machine you're using to build, how
busy it is, and other factors.  See my measurements and analysis at
http://opensolaris.org/os/community/tools/gcc/shadow/.  There is a
great deal of additional information about this feature living under
http://opensolaris.org/os/community/tools/gcc/.  Our observations
would indicate that x86 users would see at most a 35% increase in
*build* times; note that a full nightly actually includes lint and
other steps as well, so the total contribution to a full nightly
should be somewhat less than 30%.  On machines with many CPUs and
sufficient memory, shadow compilation contributes almost nothing to
build times.  It's possible that your machine is paging too heavily as
a result of this additional activity; in that case, you may benefit
from a reduction in DMAKE_MAX_JOBS.

Disabling shadow compilation is reasonable in several circumstances:

- If you have an older workspace that you can't yet update to include
the necessary source fixes.  The older sources contain bugs that will
cause your build to fail with the latest tools.  The flag day notice
at http://opensolaris.org/os/community/tools/gcc/flagday/ discusses
this.

- If you are building _un_modified ON sources for personal use only.
But, in this case, why not just use a binary distribution instead?

- If you are building _modified_ ON sources for personal use only, and
you do not care whether you have introduced bugs that gcc might warn
you about (put another way, it's more important to you that your
binaries be built sooner than that they work correctly).

Be aware that all putbacks to ON must be cc, lint, and gcc clean.
Code which is to be backported to S10 also may be built with gcc for
delivery into shipping products.  If you disable shadow compilation,
you may miss warnings you have introduced, and you will later be
backed out or required to fix these warnings.  If your usage model
does not fall into one of the above scenarios, I strongly recommend
you leave shadow compilation enabled.  If you just want to save time,
do an incremental build or build by hand in the subdirectory of
interest.

I am currently working on a couple of changes to the compiler wrapper,
most notably 6406661 and 6406667, which together will provide more
information about shadow compilation at the top of your nightly
mail_msg, and inform you if it has been disabled.

-- 
Keith M Wesolowski              "Sir, we're surrounded!" 
Solaris Kernel Team             "Excellent; we can attack in any direction!" 
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to