> Just wanted to add a couple of MIPS-specific things on top of what Joseph > said: > > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > 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? > > FWIW, n32/n64 is always fp64 -- we don't support an fp32 version.
Sorry I meant N32/N64 being link incompatible with N32/N64+MSA. > And as you imply, o32+fp64 is already an established ABI so I think we have > to support the current form alongside any new one. I agree with Joseph that > it'd be better to realign the stack dynamically instead. > This is what x86 does, so it's well tested within gcc. I see that x86 includes support for a DRAP register which as far as I can tell improves debug'ability and the generated code when dynamic stack realignment is triggered. Any thoughts on whether defining a DRAP register for MIPS would be worthwhile if we were to rely on dynamic realignment? > > Also, I think there was a possibility of adding a 256-bit form of MSA in > future, > is that right? So if we added extra static alignments, would we need a > separate ABI for 256-bit MSA too? Personally, I'd want to avoid further ABIs if MSA ever got extended to 256bit and I would expect there would also be some desire to interlink the current MSA with future extensions which would make further ABI variants undesirable. Adding extra static alignments now would therefore seem like a bad precedent to set. Going back to a point from Joseph: > * 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. I assume we could define architecture specific types with the same layout as GNU C generic vectors and differentiate between the two giving the user the choice of which to use and have GNU C generic vectors stay with existing calling convention. I guess arch specific types are defined by tagging them with an attribute? > 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). The MSA registers are not completely new but rather wider registers that overlay with the standard FP registers... I think this therefore causes further issues as use of the corresponding FP registers would clobber the MSA values even if the underlying FP registers were call-saved (the extended part of the register is zero'd when used as scalar FP). Matthew
