[PATCH] Implements -mfpu=softvfp+variants on ARM driver

[Bernard Ogden]

What I'm concerned about is that, at least for armcc, -mfpu=<fp arch>
means hard float PCS. So the new behaviour looks like the armcc
behaviour, but is different w.r.t. calling convention.

In GNU-land, it looks like the only valid parameter of this form is
softvfp+vfp, and that only gas accepts this parameter.

So although its nice to generalise this to something similar to the
armcc behaviour, perhaps the right thing to do here is to support the
GNU behaviour only (i.e. just support softvfp+vfp, which seems not to
be legal in armcc). Updating the kernel makefiles would be even
better, if that's a reasonable thing to do (I don't know why the
assembler needs to care about PCS, but I expect that's ignorance).

If you want to go with the generalised form then I think that a
warning that -mfpu=<fparch> does not select hard float would be a Good
Thing.

Regards,

Bernie


On 18 Feb 2014, at 12:47, Renato Golin <renato.golin at linaro.org> wrote:

> On 18 February 2014 12:20, Bernie Ogden <bogden at arm.com> wrote:
>> Just thought: what does -mfpu=<fp arch> (i.e. without the 'softvfp+' part)
>> mean now? It could mean 'calling convention unspecified' or it could mean
>> 'hardfloat'. I think it should mean the latter, to be consistent with the
>> armcc/gcc usage, but I _think_ that means changing the default calling
>> convention? I don't like changing defaults - does the community (or you)
>> have any position on this?
> 
> Hi Bernie,
> 
> My patch changes nothing on that respect. The default float ABI is
> still mandated by the target triple and other flags which have their
> own ways of defining the float ABI (and I won't get into the details,
> because they're rather confusing).
> 
> The only conflict that arises is what Joerg spotted, which is that
> some hard-float triples may still want soft-float ABIs. For instance,
> setting the triple to arm-linux-gnueabihf will set -float-abi=hard,
> and setting -mfpu=softvfp will set +soft-float-abi, which are
> contradictory.
> 
> I don't have enough knowledge of all the edge cases to infer what's
> the intended behaviour in this case, so I just left a warning and
> dealt with it as if the user meant -mfpu=none, which is not ideal but
> it's the least disruptive.
> 
> If the mfpu should take precedence, than we should dig through the
> previous float-abi options and remove if it conflicts with sofvfp. If
> not, the current behaviour is correct. If last-set-is-correct, than
> just adding the soft-float-abi regardless is the correct behaviour.
> I'm ok with any of them, as long as this is what people expect. Joerg
> mentioned that the kernel folks might want that, I'll check in the
> LLVMLinux and Linaro lists for what do they think the behaviour should
> be...
> 
> cheers,
> --renato
>