Re: [parisc-linux] Compiler switches

[Matthew Wilcox <willy@debian.org>]

On Sat, Feb 01, 2003 at 11:56:40PM -0500, John David Anglin wrote:
> > -D__linux__ looks like it can go away.
> 
> Agreed.  This is defined for sure in 3.1/3.2 and later.

Plus there's very little code which checks for __linux__ in the source tree ;-)

> > -fno-strength-reduce has been there since before we moved to ELF -- over 3
> > years.  Any bug this was working around has hopefully been long-squashed.
> > I think we should eliminate this and submit PRs if it finds new holes.
> 
> I always wondered why this option was used.

OK, I'll take it out now.

> > -mno-space-regs & -mfast-indirect-calls can also go away, I think.
> > I can't imagine that we ever didn't have them as default on a gcc
> > 3.0-based compiler.
> 
> These are still not the default but possibly they should be.
> 
> Actually, I can see that we can save a couple of instructions when
> generating long indirect calls to a symbol reference when no space
> registers is defined.

I think they definitely should be implied by configuring for hppa-linux.
I don't see any enthusiasm for allowing use of additional space registers
for special purposes.

> > Do we still need -ffunction-sections?  I'm inclined to leave it anyway
> > to enable compilation with older toolchains.
> 
> Cross my fingers, but I believe that the distance problem for calls
> is fixed 3.2.2.  However, if there really are objects with .text larger
> than 240000 bytes, then you should probably still define -ffunction-sections.

hmm.. part of the problem is the ld -r steps.  The current 2.5 build
process does things like:

  hppa-linux-gcc -Wp,-MD,drivers/block/.loop.o.d -D__KERNEL__ -Iinclude -Wall -W
strict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -D__linux_
_ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpr
egs -ffunction-sections -march=1.1 -mschedule=7100LC -fomit-frame-pointer -nostd
inc -iwithprefix include    -DKBUILD_BASENAME=loop -DKBUILD_MODNAME=loop   -c -o
 drivers/block/loop.o drivers/block/loop.c

   hppa-linux-ld   -r -o drivers/block/built-in.o drivers/block/elevator.o drive
rs/block/ll_rw_blk.o drivers/block/ioctl.o drivers/block/genhd.o drivers/block/s
csi_ioctl.o drivers/block/deadline-iosched.o drivers/block/rd.o drivers/block/lo
op.o

   hppa-linux-ld   -r -o drivers/built-in.o drivers/pci/built-in.o drivers/paris
c/built-in.o drivers/serial/built-in.o drivers/parport/built-in.o drivers/base/b
uilt-in.o drivers/char/built-in.o drivers/block/built-in.o drivers/misc/built-in
.o drivers/net/built-in.o drivers/media/built-in.o drivers/scsi/built-in.o drive
rs/cdrom/built-in.o drivers/video/built-in.o drivers/usb/built-in.o drivers/inpu
t/built-in.o drivers/input/serio/built-in.o drivers/md/built-in.o drivers/eisa/b
uilt-in.o

        hppa-linux-ld  -T arch/parisc/vmlinux.lds.s arch/parisc/kernel/head.o   
init/built-in.o --start-group  usr/built-in.o arch/parisc/kernel/pdc_cons.o arch
/parisc/kernel/process.o  arch/parisc/mm/built-in.o  arch/parisc/kernel/built-in
.o  arch/parisc/hpux/built-in.o  arch/parisc/math-emu/built-in.o arch/parisc/ker
nel/init_task.o  kernel/built-in.o  mm/built-in.o  fs/built-in.o  ipc/built-in.o
  security/built-in.o  crypto/built-in.o  lib/lib.a  arch/parisc/lib/lib.a `hppa
-linux-gcc -print-libgcc-file-name`  drivers/built-in.o  sound/built-in.o  arch/
parisc/oprofile/built-in.o  net/built-in.o --end-group  -o vmlinux

Now, which .text is limited to 240k?  loop.o, drivers/block/built-in.o,
drivers/built-in.o or vmlinux?

> When the total code bytes exceeds the above limit (PA 1.X), gcc switches
> to long indirect calls.  These are horribly inefficient.

Horribly inefficient in terms of being prefetchable?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk