This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [csl-arm-branch] Clean up FPU target flags


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]