llvm dev - Mar 2017 - clang 4.0.0: Invalid code for builtin floating point function with -mfloat-abi=hard -ffast-math (ARM)

On 22 March 2017 at 01:38, Friedman, Eli <efriedma at codeaurora.org>
wrote:
>> Small example fail.c:
>>
>>    // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard
-ffast-math
>> -S fail.c -o -
>>    extern float sinf (float x);
>>    float sin1 (float x) {return (sinf (x));}
I changed your example slightly to make sure we're passing the
arguments, otherwise 'sin1' just becomes 'b sinf', which is
"correct"
on both hard and soft float.

extern float sinf (float x);
float sin1 (float x, float y) {return (sinf (y)+x);}

>> generates code to pass the parameter in r0 and expect the result in r0.
>> The same code without -ffast-math compiles correctly. It also works
with
>> -fno-builtin-sinf.
Right, so this is the problem. You're declaring a function that is
declared in the C library, and the compiler will try and match it with
what it understands of the ABI (via builtins).

In this case, GCC and Clang "understand" different things about them,
and I'm not saying Clang is right. But if you want to use your own
sine functions, using -fno-builtin-sinf is the *right* way to go.

So, now that you have a work around that makes sense (and can progress
without us blocking you), let's talk about the problem at hand.

> It would be more accurate to say -ffast-math makes the compiler treat sin()
> as a builtin, and therefore recreate the declaration from scratch.
Precisely.

But the problem is not as simple as it seems. We had a conversation
about this during the US LLVM last year, and the conclusion is that
soft-float ABI functions should always have soft-float calling
conventions (GCC seems to agree). But sin/cos are not soft-fp
functions at all.

Looking at the patch, sin/cos wasn't wrongly bundled with the soft-fp
nodes, so it's possible that fast-math is combining nodes, thus
changing the behaviour of the selection dag wrt calling conventions.

Saleem,

Any light on why is sin/cos bundled with soft-fp handling?

cheers,
--renato

On Fri, Mar 24, 2017 at 4:27 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 22 March 2017 at 01:38, Friedman, Eli <efriedma at codeaurora.org>
wrote:
> >> Small example fail.c:
> >>
> >>    // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard
> -ffast-math
> >> -S fail.c -o -
> >>    extern float sinf (float x);
> >>    float sin1 (float x) {return (sinf (x));}
>
> I changed your example slightly to make sure we're passing the
> arguments, otherwise 'sin1' just becomes 'b sinf', which is
"correct"
> on both hard and soft float.
>
> extern float sinf (float x);
> float sin1 (float x, float y) {return (sinf (y)+x);}
>
>
> >> generates code to pass the parameter in r0 and expect the result
in r0.
> >> The same code without -ffast-math compiles correctly. It also
works with
> >> -fno-builtin-sinf.
>
> Right, so this is the problem. You're declaring a function that is
> declared in the C library, and the compiler will try and match it with
> what it understands of the ABI (via builtins).
>
> In this case, GCC and Clang "understand" different things about
them,
> and I'm not saying Clang is right. But if you want to use your own
> sine functions, using -fno-builtin-sinf is the *right* way to go.
>
> So, now that you have a work around that makes sense (and can progress
> without us blocking you), let's talk about the problem at hand.
>
>
> > It would be more accurate to say -ffast-math makes the compiler treat
> sin()
> > as a builtin, and therefore recreate the declaration from scratch.
>
> Precisely.
>
> But the problem is not as simple as it seems. We had a conversation
> about this during the US LLVM last year, and the conclusion is that
> soft-float ABI functions should always have soft-float calling
> conventions (GCC seems to agree). But sin/cos are not soft-fp
> functions at all.
>
> Looking at the patch, sin/cos wasn't wrongly bundled with the soft-fp
> nodes, so it's possible that fast-math is combining nodes, thus
> changing the behaviour of the selection dag wrt calling conventions.
>
> Saleem,
>
> Any light on why is sin/cos bundled with soft-fp handling?
>
sin/cos are libm functions, and so a libcall to those need to honour the
floating point ABI requests.  The calling convention to be followed there
should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP,
-mfloat-abi=soft => AAPCS).

> cheers,
> --renato
>
-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170328/206ca5b9/attachment.html>

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:
> sin/cos are libm functions, and so a libcall to those need to honour the
> floating point ABI requests.  The calling convention to be followed there
> should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP,
> -mfloat-abi=soft => AAPCS).
Exactly, but they're not, and that's the problem. Do you have any idea
why -ffast-math would change their PCS for libc calls?

The behaviour seems to have been by your patch
(https://reviews.llvm.org/rL291909), so maybe there's some
transformation that uses the run-time functions, or some other badly
coupled logic...

cheers,
--renato