Thomas Preudhomme <robo...@celest.fr> writes: >> I think the ability to detect the case of generating ABI agnostic >> code would be useful for other architectures too. > > I do not know the other architecture to know if that is the case but > according to what you said for MIPS it seems to be the case. Right now I > implemented it completely in the backend but that can be done in middle > end if several architecture would benefit from it.
Yeah, that'd be great. The checking that MIPS's -mno-float should do (but doesn't do) would be a superset of what you need, since the MIPS case would include internal uses of floats. But it would definitely make sense to share the bits that can be shared and (for example) to get consistent error messages for them. > I did not do it because I thought that other architecture might care > more about different kind of ABI like the calling convention for long > long on 32 bit architectures or structure or bitfield. I did not know > if the calling convention for float parameter mattered to other > architecture. Also in the case of ARM a structure of up to 4 > floats/double would be passed via float registers so that would be > counted as a float but maybe not for MIPS. So a common switch for > several architecture might be strange if each interpret it in a > different way. How about warning for all float types (as the float option) and all vector types (as a separate option)? I'm not sure there's as much value in warning specifically about "hardware" types since that can always change in future. E.g. a while ago the only MIPS vector of interest was V2SF, but then Loongson added some integer ones, and now MSA is adding 128-bit vector types. There could be wider types in future, as happened for 512-bit AVX. >> MIPS does have an option for something similar to this which is >> -mno-float but it does not really do what you are aiming for here. >> The >> -mno-float option marks a module as float ABI agnostic but actually >> performs code gen for a soft-float ABI. It is up to the programmer to >> avoid floating point in function signatures. Perhaps this option >> would >> be useful to support the enforced compatible ABI but being able to >> relax the ABI is better still as it would require no effort from the >> end user. I'm planning on proposing these kind of changes for MIPS in >> the near future. > > Yeah that's different to no-float here since the body of functions can > use float arithmetic and even function interface as long as they are not > public. I am interesting in knowing what exactly is your use case, what > is the difference for the calling convention with regards to float on > MIPS architecture. Maybe it's just a matter to choose the right name for > the switch such as -mabi-agnostic or something? -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. But the restrictions that apply to -mno-float should make it link-compatible with -mhard-float too, as for your use case. Thanks, Richard
