This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [csl-arm-branch] Clean up FPU target flags
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Mark Mitchell <mark at codesourcery dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Sat, 06 Dec 2003 15:50:53 +0000
- Subject: Re: [csl-arm-branch] Clean up FPU target flags
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
Paul, Mark
Before reviewing the mechanics of the patch (which I don't think will be a
problem) I want to be happy with the meanings of the options we are trying
to add here, and how that will be reflected in the documentation. That
applies both to this patch and the assembler patch.
The patch is proposing that a -mfpu option be added, but that
-msoft/hard-float be kept. These options are interdependent, so it is
important to understand what the matrix of possible options mean. Some of
the combinations may be obvious, others less so. What does it mean, for
example, to use "-mfpu=vfp -msoft-float"? How do we tell the compiler we
want to use VFP instructions in the body of a function, but to use the
soft-float ABI for function calls?
Given possible settings of -mfpu of fpa, vfp, maverick (and some legacy
FPE variants, but I'll ignore those, since they really are just variants
of fpa) and -msoft/hard-float we have the table:
hard-float soft-float
+----------+----------+
vfp | 1 | 2 |
+----------+----------+
fpa | 3 | 4 |
+----------+----------+
maverick | 5 | 6 |
+----------+----------+
Now clearly combinations representing 1, 3 & 5 are potentially meaningful,
but what do combinations 2, 4 and 6 represent? And how do we encode the
procedure-calling standard variant?
I believe that it is in fact meaningful to use -msoft-float and the
various fpu options together, and the meaning is that this selects the
format of the floating point numbers used (ie -mfpu=fpa, -msoft-float
gives us the FPA-style mixed-endian floating point numbers as used in
traditional ARM systems, whereas -mfpu=vfp -msoft-float will use
pure-endian floating point values as defined by the "ABI for the ARM
Architecture"; -mfpu=maverick -msoft-float will use what-ever FP format is
used by the Maverick chip, which I believe is pure-endian, though I've not
seen the documentation for the chip).
Now it clearly doesn't make sense to pass floating point arguments in
floating point registers when you don't have any floating-point registers!
So the problem really is what does hard-float mean, since it covers two
possible variants: using the floating-point registers purely within a
function (but all arguments and return values are passed in integer
registers), or using the floating-point registers for passing arguments
and returning results?
One possibility is to add an orthogonal option (say, -m[no-]float-abi)
which selects between the two variants, but clearly this option would be
meaningless with -msoft-float. So another possibility would be to add a
third option to the hard-float/soft-float group.
Now I believe that all existing uses of hard-float have effectively mapped
onto the variant of the ABI that uses floating-point registers in the
calling convention (for FPA this is only used for the return value, but
the effect is that it does change the ABI). So it might make more sense
to have:
-mfloat-abi=xxx
where xxx is one of soft, soft+fp and hard. We could then map
-mhard-float onto -mfloat-abi=hard, -msoft-float onto -mfloat-abi=soft and
the third option would stand on its own as the new variant and mean: use
the soft-abi, but you can use floating-point instructions (for the
selected floating-point hardware) in the body of the function.
This would give us the table
-mfloat-abi=
hard soft+fp soft
+-------+-------+-------+
vfp | 1 | 2 | 3 |
+-------+-------+-------+
-mfpu= fpa | 4 | 5 | 6 |
+-------+-------+-------+
maverick | 7 | 8 | 9 |
+-------+-------+-------+
and all 9 points in the matrix would have a valid meaning even if they
aren't implemented in the compiler. It is possible that some of the
points in the matrix will generate identical code (for example variants 3
and 9), but I don't think that is a problem.
Does this make sense to you?
R.