This is the mail archive of the
mailing list for the GCC project.
Re: [RFC PATCH, x86_64] Use -mno-sse[,2] to fall back to x87 FP argument passing convention
- From: Ian Lance Taylor <iant at google dot com>
- To: "Uros Bizjak" <ubizjak at gmail dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>
- Date: 10 Oct 2006 22:35:03 -0700
- Subject: Re: [RFC PATCH, x86_64] Use -mno-sse[,2] to fall back to x87 FP argument passing convention
- References: <firstname.lastname@example.org>
"Uros Bizjak" <email@example.com> writes:
> Attached RFC patch can be used to specify where FP arguments of
> different modes are passed. It is suprisingly short, as it piggybacks
> on existing XFmode functionality (XFmode arguments are always passed
> via x87 registers). So, specifying -mno-sse2 now passes DFmode
> arguments using x87 passing convention, instead of emitting an error
> that SSE register is used without SSE enabled.
Side-stepping the whole following discussion, I want to agree with a
couple of other people that we should not change the ABI with an
option like -mno-sse2. We should use a different option, probably
-mabi= along the lines of ARM, MIPS, PPC, etc.
It would be perfectly reasonable to give an error referring to the new
option if -mno-sse2 is used for x86_64 and the code passes floating
point values anywhere. Or just always give an error for -mno-sse2.
I also think that we should add the option to the assembler, and
record the information in the .o file somewhere--the usual place would
the e_flags field of the file header, but since x86_64 ELF is so
widely used it might be better to use a GNU note of some sort. Then
the linker can give a warning or error about attempts to link together
files with mismatched ABIs. I think that would be quite an important
warning for a platform like x86_64 ELF for which many people
distribute precompiled libraries.
Incidentally, I've thought that it might be interesting to experiment
with an x86_64 ABI which used ILP32, but which used the extra eight
registers, passed parameters in registers, and only preserved the low
32-bits of the caller-saved registers. For applications which could
live in a 32-bit address space, that would save the memory traffic
required to save and restore 64-bit registers on function entry and
exit. The result would be pretty similar to i386 code, but with 8
more registers. It should definitely run faster than i386 code, and I
think that due to improved memory traffic it would also run faster
than standard x86_64 code. But I haven't actually tried.