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

[Saleem Abdulrasool via llvm-dev]

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>