build report

[Joe Harrington]

> Err, I think the build instructions do tell you that you need a new
> binutils for i686-pc-linux-gnu.

> http://www.cygnus.com/egcs/install/specific.html

True.  But, I missed it first time around, and so will others.  It
would be good to put a link to this before "configure" in index.html
(where you point people from the main README).  I'd also note the need
for a new dejagnu and possibly a new texinfo.  In general, make
dependencies that differ from release GNU systems *prominent* in any
instructions.

Two docs bugs: First, texinfo.texi gives 16 errors on each of its 3
runs in make dvi.  Second, the command line to format g77.texi
includes a -I, which isn't understood by the texinfo-3.9 installed on
this Red Hat 5.0 box.  A pointer to a later version of TeXinfo or use
of the version included in the egcs release might fix these if they're
not actual bugs.

>  > Also, a summary of new features compared to the current gcc release
>  > would be great.  I tried putting -m686 in my BOOT_CFLAGS but it didn't
>  > like it.  Ok, so how do you get the pentium and PPro scheduler?  That
>  > kind of thing.
> Look at the egcs-1.0.1 release page:

Thanks.  Perhaps put in a link from the included docs?  I see that
Pentium and PPro stuff is mentionned there, but see nothing in the man
page about turning them on.  AH!  It's in the info but not in the man
page.  Updating the man page would be good.

Gcc's default target architecture for the x86 series seems broken.
Why is the default to build for the *oldest* machine, rather than the
*user's* machine?  It's true that many people want a single binary to
run on all x86 hardware, so it's important to be able to generate 386
code.  However, it's also true that *most* people don't need or want
their binary to run on more than one machine, and that there are few
386's out there by comparison to later CPUs.  It would seem best to
default to the user's CPU, rather than the oldest hardware in the
series of his or her CPU.  Using -mwhatever should be the exception,
not the rule.  If the default-to-oldest convention is here to stay,
please at least give us a -mcurrent that creates code for the current
CPU.

I have found another difficulty with the -m options.  I maintain a set
of install scripts called the Clue Files
( ftp://oobleck.tn.cornell.edu/pub/clues-yy.mm.dd.tar.gz ).  They
provide cut-and-paste instructions for installing your /usr/local in a
robust, reproducible, maximally-optimized fashion.  I use gcc in them
so that users of different architectures all have the same
make/compile lines.  A problem is that Intel users want the equivalent
of the -mbest suggested above.  So far, I've been special-casing -m486
for users of i486, i586, and i686.  This makes the files messy, but is
necessary.  Egcs lets Intel users do -mcpu=`uname -m` (great, almost
as good as -mcurrent!), but Intel is still a special case since not
all hardware allows -mcpu.  It would be great if it did, so that
-mcpu=`uname -m` compiles for the current CPU, even if there's only
one architecture definition for several processors.  Of course, having
a -mcurrent that is understood on all architectures obviates the need
for this.

Finally, I tested the different -m options for the x86 family on a
numerical model.  Results are not what I'd expect:

		with Haifa		no Haifa
-m		t1	t2	t3	t1	t2	t3	
386		11.70	18.19	8.49    11.68   18.21   8.55
486		11.65	18.18	8.47    11.74   18.17   8.50
pentium		11.69	18.12	8.48    11.75   18.22   8.50
pentiumpro	11.72	18.20	8.52    11.69   18.16   8.56

t1 is a numerical model with lots of adds and multiplies
t2 is the same but with lots of trig functions added
t3 is like t1 but accesses a large sparse array (fewer iterations)

Times are wall clock as reported by csh's built-in time command, with
CPU usage reported at 100%.  I took the best of three trials in each
case.  Results were quite consistent between the trials, usually
within 0.01 second of each other.

I'm on a PII, so I'd expect the last times to be the shortest by a
substantial margin.  Instead, the differences are significant only in
a statistical sense, there's no consistent pattern to which runs
fastest, and often the code supposedly generated for this CPU runs the
slowest!  Wouldn't you expect to see a substantial improvement between
code generated for a 386 and code generated for a 686, when you run on
a 686?

Thanks again for your work on gcc.  The Bazaar is a win!

--jh--