Message-Id:	<199711191706.MAA00693@delorie.com>
From:	Oberhumer Markus <k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at>
Subject:	971114: build system
To:	djgpp-workers AT delorie DOT com (djgpp-workers), dj AT delorie DOT com (DJ Delorie)
Date:	Wed, 19 Nov 1997 17:59:39 +0100 (MET)
Return-Read-To:	markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at
Mime-Version:	1.0

Subject: 971114: build system

The new libc build system works very fine for me.

Some notes:

- the 'fake' command-line echoing from make is a little confusing
  at the first time

- a little patch for makefile.lib follows below

- make.sh should be renamed (e.g. makelib.sh) to avoid problems
  when using bash or 4DOS (where you may have .sh files start bash)

- I agree with Laszlo and suggest building with '-O2 -fno-strength-reduce'.
  Functions that really should be inlined can be marked as 'inline'
  in the library sources.

  Note: -fno-strength-reduce has nothing to do with the bug in
    previous versions of gcc.

  An excerpt from the Linux GCC-HOWTO follows below, and my own tests
  also have shown that strength-reduction on a i386 usually produces
  slower code.


Markus


*** MAKEFILE.LIB.ORG	Fri Nov 14 18:49:32 1997
--- MAKEFILE.LIB	Tue Nov 18 22:18:58 1997
***************
*** 14,17 ****
--- 14,19 ----
  endif
  
+ include $(TOP)/../makefile.inc
+ 
  $(LIB)/lib$(LIBNAME).a : $(OBJS) makefile.rf $(TOP)/../ident.c
  	$(CROSS_GCC) -c -DLIB=lib$(LIBNAME) $(TOP)/../ident.c -o id_$(LIBNAME).o
***************
*** 28,33 ****
  	$(CROSS_AR) q $(LIB)/lib$(LIBNAME).a @makefile.rf id_$(LIBNAME).o
  	$(CROSS_AR) s $(LIB)/lib$(LIBNAME).a
- 
- include $(TOP)/../makefile.inc
  
  clean ::
--- 30,33 ----




From the Linux GCC-HOWTO:
=========================

  4.2.1.1.  Processor-specific

  There are other -m flags which aren't turned on by any variety of -O
  but are nevertheless useful.  Chief among these are -m386 and -m486,
  which tell gcc to favour the 386 or 486 respectively.  Code compiled
  with one of these will still work on the other; 486 code is bigger,
  but otherwise not slower on the 386.

  There is currently no -mpentium or -m586.  Linus suggests using -m486
  -malign-loops=2 -malign-jumps=2 -malign-functions=2, to get 486 code
  optimisations but without the big gaps for alignment (which the
  pentium doesn't need).  Michael Meissner (of Cygnus) says

       My hunch is that -fno-strength-reduce also results in faster
       code on the x86 (note, I'm not talking about the strength
       reduction bug, which is another issue).  This is because the
       x86 is rather register starved (and GCC's method of grouping
       registers into spill registers vs. other registers doesn't
       help either).  Strength reduction typically results in using
       additional registers to replace multiplications with addi­
       tion.  I also suspect -fcaller-saves may also be a loss.

       Another hunch is that -fomit-frame-pointer might or might
       not be a win.  On the one hand, it can mean that another
       register is available for allocation.  On the other hand,
       the way the x86 encodes its instruction set, means that
       stack relative addresses take more space instead of frame
       relative addresses, which means slightly less Icache avail­
       ble to the program.  Also, -fomit-frame-pointer, means that
       the compiler has to constantly adjust the stack pointer
       after calls, while with a frame, it can let the stack accu­
       mulate for a few calls.

  The final word on this subject is from Linus again:

  Note that if you want to get optimal performance, don't
  believe me: test.  There are lots of gcc compiler switches,
  and it may be that a particular set gives the best optimiza­
  tions for you.

- Raw text -