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

[Renato Golin via llvm-dev]

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