RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

["Thomas Preud'homme" <thomas dot preudhomme at arm dot com>]

> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]

> 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 agree on the error messages and on a common switch. I am not sure for the rest though (see below).

> 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.

I do not think it is a good approach. First, it means on ARM a user would need to use several switches to test compatibility and at least one part would be ARM specific (vector of less than 4 float/double). Second, when the function is variadic ARM use the base calling convention, no matter what is the calling convention normally used. So a float in a variadic function is not a problem for ARM but might be a problem for MIPS. I agree though that there is an overlap with the -no-float switch of MIPS. On the other hand checking for the dual compatibility of an ARM code is just about 15 lines of code and doing this in middle end with some hooks for architecture specific bits would make the code much bigger I think. I'll think some more about it and give you a more decided opinion. Right now my mind is not set.

> -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.

Right. With your explanation and the description of the -mno-float switch I now understand what it does. So as I said, there is an important overlap with my work and if I can find an approach that manage to share some code I will do that. I am unsure at present about whether it is a good thing to do. I believe a new switch is necessary since what I need for ARM is slightly different than -mno-float meaning. The logic could be partially shared if it is not too complicated to do so.

Best regards,

Thomas