Laurent GUERBY <laur...@guerby.net> writes:
> I was wondering why mips64*-*-linux does not have the same
> handling of multiarch as powerpc/sparc/x86 in gcc/config.gcc:
> 32 bits compiler binaries with 32/64 target choice via "-m", --with-cpu
> and --enable-targets support for configure. Is there any specific reason
> for this?
>
> If reason is "just not done", what model should we follow - copy/paste
> from? Patch or patch sketch welcomed, we have mips64 machines to play
> with in the GCC Compile farm :).
I don't think there's much reason to use a 32-bit compiler binary.
-mabi=n32 is designed to be an ILP32 ABI that is _mostly_ type-compatible
with -mabi=32, but with the ability to use 64-bit registers. And using
64-bit registers is fairly important for gcc, because we require 64-bit
HOST_WIDE_INTs.
When I did some performance measurements a few years back -- probably
on a VR413x -- n32 did give a noticeable improvement over o32.
We have a policy on MIPS not to infer an ABI from a architecture option.
We don't want a 64-bit architecture to switch from o32 to a 64-bit ABI
because:
(a) Some 64-bit architectures add more than just 64-bit support.
MIPS IV has new instructions that can be used in 32-bit code too,
so -mips4 -mabi=32 is a very useful combination. The same is true
for processor-specific extensions, such as those found on the
RM and VR series. It would be confusing for:
32bit-gcc -march=mips4 ...
to produce 64-bit code, forcing the user to use the
tautologous:
32bit-gcc -mabi=32 -march=mips4 ...
to actually get 32-bit code.
(b) There are two ABIs to choose from.
There's no --with-cpu support because MIPS doesn't have an -mcpu option.
When the MIPS options were revamped a few years ago, the general GCC
consensus (among those who offered an opinion) was that ports should
use -march to control ISA selection and -mtune to control optimisation.
It was thought -mcpu was too confusing: some ports treated it as a
tuning option and some treated as an architecture option. (And indeed,
-mcpu is supposedly deprecated for x86, though it's unlikely to ever go away.)
I think the lack of --with-arch-{32,64}, --with-tune-{32,64} and
--enable-targets options is in the "not yet done" category.
Richard
