build report

build report

[Joe Harrington]

I successfully built egcs-1.0.1 under i686-pc-linux-gnu.  Seems to
install fine.  Minor build problems:

make dvi
# 16 returns required, three times
texi2dvi -I../../gcc/f ../../gcc/f/g77.texi -o f/g77.dvi
texi2dvi: Unknown or ambiguous option `-I../../gcc/f'.
texi2dvi: Try `--help' for more information.
make[1]: *** [f/g77.dvi] Error 1
make[1]: Leaving directory `/home/local/src/egcs-1.0.1/objdir/gcc'

In general, your build requires a lot of late-model software.  It
would be nice to see the packages needed listed up front, boldly.  I
built the whole compiler and then discovered I needed a new binutils.

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.

Also also, there's this tantalyzing hint about Haifa.  Does it produce
*worse* code on any platform?  I.e., is it unsafe to use it by
default?  Is it related to improved scheduler support for 586 and 686?
There are about 5 lines in the various docs about it, and they just
talk about how to turn it on or not.  Is there a way to select it a
gcc runtime?

Thanks for doing egcs?  The pace of improvement has been maddeningly
slow.

--jh--

Re: build report

[Jeffrey A Law]

  In message < 199802051938.OAA27614@oobleck.tn.cornell.edu >you write:
  > In general, your build requires a lot of late-model software.  It
  > would be nice to see the packages needed listed up front, boldly.  I
  > built the whole compiler and then discovered I needed a new binutils.
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

i?86-*-linux*
You will need binutils-2.8.1.0.15 or newer for exception handling to work. 

  > 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:

http://www.cygnus.com/egcs/egcs-1.0.1.html

It describes the new stuff in egcs-1.0.1 as well as comparing it to gcc-2.8.

  > Also also, there's this tantalyzing hint about Haifa.  Does it produce
  > *worse* code on any platform?
It could.  It requires tuning of the machine description  to more closely
match how the processor actually works -- many machine descriptions lied
about the processor's pipeline to try to get better performance out of
the old scheduler.

Also on register poor machines like the x86, the more aggressive scheduling
done by the haifa scheduler may increase register pressure and lead to
worse code.

  > I.e., is it unsafe to use it by default?
Nope.  1.0.1 has it on by default for the PA.  Current snapshots have it
on for the PA, rs6000/ppc and alpha -- those are the ports that have been
tuned to work with the haifa scheduler.

  > Is it related to improved scheduler support for 586 and 686?
  > There are about 5 lines in the various docs about it, and they just
  > talk about how to turn it on or not.  Is there a way to select it a
  > gcc runtime?
No, there's no way to select it at runtime; it's a configure time only
option.

jef

Re: 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--

Re: build report

[Jeffrey A Law]

  In message < 199802061743.MAA28101@oobleck.tn.cornell.edu >you write:
  > 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.
No matter where we put it folks are going to miss it.  IMHO the target
specific stuff belongs *after* the other stuff since it's not likely 
to make such sense if you don't have some clue about the overall configure
and build procedure.

  > 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.
Hmmm, we haven't run make.dvi...  Sigh.

Can you find out why it didn't use the texinfo in the distribution?  The
whole point of including it is to prevent this kind of problem.

  > 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.
Sigh.  Yes, this is an age-old problem with GNU tools -- nobody updates
the man pages because the "info" documentation is the official stuff.

  > 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 been our experience that providing the LCD code generation tends to
be a better default.  Most folks that care about performance will take the
time to find the additional options to tune optimization for their
particular chip.   Either way there's going to be a group of folks that
think the default is wrong :-)

  > 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
  > 
[ ... ]

  > 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?
In theory, yes, but I don't think either the code generator has been well
tuned for those machines yet.  Particularly it the scheduler hasn't been
tuned, so we probably aren't getting any of the benefits of their exposed
pipeline architecture.

jeff