RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 21 Jan 2014, Matthew Fortune wrote:

> The MSA patch as submitted is another variation of O32 ABI which could 
> be described as O32+FP64+MSA(+nan2008) and would be link incompatible 
> with both O32 and O32+FP64(+/-nan2008). The same of course applies to 
> N32/N64 being link incompatible with N32/N64+FP64. This may make it 
> difficult to have a small part of an application optimised with MSA but 
> the rest of the code ignorant of MSA, in your experience do you think 
> that will be an issue?

In general, unnecessary ABI incompatibility is to be discouraged.  This 
means (I'm talking about all architectures, not just MIPS):

* Use dynamic stack realignment rather than increasing the alignment 
assumed by callees.

* New registers should be call-clobbered, so setjmp/longjmp (and *context 
functions) don't need to save and preserve them.

* Do not change layout or alignment of existing types.

* If your architecture defines that some ISA feature can only coexist with 
other ISA features (for example, that it can only coexist with hardware 
floating point, or only with 64-bit support) then that may reduce the 
number of ABI variants that need to be defined.

* If you want to pass vector arguments (or return values) in new 
registers, without affecting the ABI for any non-vector argument or return 
type, we're a bit more relaxed on that - but if this affects GNU C generic 
vectors rather than just architecture-specific vector types there should, 
at least, be a -Wpsabi warning about the ABI change implied by enabling 
the vector instructions.  Alternatively, enable such argument passing only 
with an ABI option e.g. -mmsa-abi, rather than with the same option that 
enables the new instructions.  In either case, you need to make sure the 
dynamic linker is built with the new instructions disabled, to avoid it 
clobbering the new registers (just as it generally needs special handling 
for call-clobbered registers involved in argument passing).

* In any case, write an ABI document at an early stage that documents how 
the new registers interact with the ABI.

If you do conclude that you need a new, incompatible ABI, then the 
following also apply - see the NaN2008 changes for recent MIPS examples:

* Ensure the static linker gives errors for linking incompatible objects 
(whether with GNU object attributes, ELF header bits, or some other 
mechanism).

* For glibc, define new dynamic linker names (see recent discussion on the 
glibc lists) and ensure the corresponding specs in GCC pass the right 
arguments to -dynamic-linker.

* Ensure that glibc can tell executables / shared libraries for the 
different ABIs apart by examining the ELF header, ensure 
elf_machine_matches_host checks compatibility, and ensure ldconfig handles 
the different kinds of executables / shared libraries 
(_DL_CACHE_DEFAULT_ID, readelflib.c:process_elf_file, etc.).

-- 
Joseph S. Myers
joseph@codesourcery.com