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
