ppc64 builds

[Jakub Jelinek]

On Mon, Mar 19, 2007 at 02:51:24AM -0400, Tom Lane wrote:
> AFAIK, not building a ppc64 version should not be a "bug", indeed it
> likely should be the default.  32-bit code runs faster than 64-bit code
> on that arch, and so the only reason to build 64-bit is if you really
> need access to more than 4Gb of address space.  There are apps that need
> that, but not all that many.
> 
> So my position is that libraries should generally be built in both
> flavors (since they can't predict which flavor of executable might want
> them) but applications should be built as 32-bit unless there's a good
> reason why they need a 64-bit address space.

On ppc/sparc yes, plus rpm should prefer there 32-bit packages over 64-bit
ones (currently it prefers 64-bit), but there should be a way to override
this on a per-package basis (things like gdb and a few others that prefer
to be 64-bit if possible).

> (If you ask me, the interesting question here is why the other arches
> don't behave the same way.  Any reasonably competent hardware design
> should have the property that doubling the bit-volume of traffic to
> main memory has a penalty...)

On x86_64 the thing that makes 64-bit code more desirable is
doubling the number of general purpose registers and a better addressing
mode for PIC code (%rip addressing).  So for most apps on x86_64 using
64-bit programs is an overall win.  On s390x 64-bit code can use direct
calls rather than always loading a function address from literal pool
and calling indirectly and a few other improvements, so I believe
running 64-bit code on s390x is as slow/fast as 31-bit code.

	Jakub