On 06/23/2016 05:06 PM, David Miller wrote:
> I think what irks people the most about what happened, is that the
> choosen a path is not the most optimal situation for the target
> platform.
Why should it be any different for sparc64 than for ppc64el, amd64,
arm64, mips64el and so on? Is SPARC so extremely inefficient with
64-bit pointers? I don't think so.
> The most desirable would have been to build the bulk of userland
> binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx
> for some v9 cpu), and then for the specific packages that need it,
> build 64-bit.
I don't think it makes sense to compile things like dateutils with
32-bit pointers for performance reasons. Also, I would assume that
modern compilers are able to optimize the code well enough that the
difference between 32-bit and 64-bit pointers isn't too big that
it justifies the effort. Some compilers like Intel's C/C++ compiler
are actually already automatically generating 32-bit code when possible,
the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar
feature in the future.