Message-Id: <199711191706.MAA00693@delorie.com> From: Oberhumer Markus 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk 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.