[parisc-linux] Compiler switches

John David Anglin dave@hiauly1.hia.nrc.ca
Sat, 1 Feb 2003 23:56:40 -0500 (EST)

> -D__linux__ looks like it can go away.

Agreed.  This is defined for sure in 3.1/3.2 and later.

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

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

> 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.
When the total code bytes exceeds the above limit (PA 1.X), gcc switches
to long indirect calls.  These are horribly inefficient.  There are
better sequences but we need some new support in gas and ld to handle
the relocations and generate appropriate stubs.

For example, the following non-pic sequence works under hpux with the HP
assembler, but not linux or hpux with gas:

	ldil L'dest,%r1
	be R'dest(%sr4,%r1)

Long pic pc-relative and symbol difference sequences also don't work.

J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)