This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH, x86_64] Use -mno-sse[,2] to fall back to x87 FP argument passing convention


"Uros Bizjak" <ubizjak@gmail.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.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]