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

[Thomas Preudhomme]

Le 2014-03-04 19:14, Matthew Fortune a écrit :
> Hi Thomas,

Hi Matthew,

>
> Do you particularly need a switch for this? You could view this as
> simply relaxing the ABI requirements of a module, a switch would only
> serve to enforce the need for a compatible ABI and error if not. If
> you build something for a soft-float ABI and never actually trigger
> any of the soft-float specific parts of the ABI then you could safely
> mark the module as no-float ABI (same for hard-float).

I was maybe not clear enough but my patch already has this logic to 
detect whether any float is used at all and emit an elf attribute 
accordingly. However, someone who wants to be compatible with both 
softfloat and hardfloat would need to look at the output to see that was 
achieved. Such a switch would allow people to actually ensure that they 
managed to create a float agnostic ABI.

> A simple check
> would be if floating point types are used in parameters or returns 
> but
> actually it could be more refined still if none of the arguments or
> returns would be passed differently between the ABI types. The 
> problem
> with relaxing the ABI is that you only know whether it can be relaxed
> at the end of compiling all functions, I am currently doing some work
> for MIPS where the assembler will be calculating overall requirements
> based on an initial setting and then analysis of the code in the
> module. To relax a floating point ABI I would expect to emit an ABI
> attribute at the head of a file, which is either soft or hard float,
> but then each function would get an attribute to say if it ended up 
> as
> a compatible ABI. If all global functions say compatible then the
> module can be relaxed to be a compatible FP ABI.

Right. It's actually quite simple. As soon as you meet a function which 
passes or returns a float then you can mark the whole module as not 
agnostic and fall back to the usual behavior. If you arrive at the end 
of a compiling unit without encoutering such a case then you are 
agnostic. You could mark each function individually but I don't think 
it's necessary to go that far. If you want only some functions to be 
compatible you could put them in a separate file. My current patch goes 
a bit beyond than this in that it only care about public interface. Call 
withing one module can use whatever calling convention they want, it 
does not change the ABI.

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

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

Anyway, thanks for your comment on this issue. It is good to know that 
there might be some other uses than just ARM.

>
> Regards,
> Matthew

Best regards,

Thomas