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

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

I think the problem is here:

llvm\lib\Target\ARM\ARMISelLowering.cpp, line 187:

   if (!Subtarget->isTargetDarwin() && !Subtarget->isTargetIOS()
&&
       !Subtarget->isTargetWatchOS()) {
     const auto &E = Subtarget->getTargetTriple().getEnvironment();

     bool IsHFTarget = E == Triple::EABIHF || E == Triple::GNUEABIHF ||
                       E == Triple::MuslEABIHF;
     // Windows is a special case.  Technically, we will replace all of 
the "GNU"
     // calls with calls to MSVCRT if appropriate and adjust the calling
     // convention then.
     IsHFTarget = IsHFTarget || Subtarget->isTargetWindows();

     for (int LCID = 0; LCID < RTLIB::UNKNOWN_LIBCALL; ++LCID)
       setLibcallCallingConv(static_cast<RTLIB::Libcall>(LCID),
                             IsHFTarget ? CallingConv::ARM_AAPCS_VFP
                                        : CallingConv::ARM_AAPCS);
   }

IsHFTarget is only true if the target is eabihf. -msoft-abi is 
completely ignored.

cheers,

Peter

Am 30.03.2017 um 00:15 schrieb Renato Golin:
> 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
>

Did anything ever happen here?  This still appears to be broken on trunk.

-Eli

On 3/30/2017 4:12 PM, Peter Jakubek wrote:
> I think the problem is here:
>
> llvm\lib\Target\ARM\ARMISelLowering.cpp, line 187:
>
>   if (!Subtarget->isTargetDarwin() &&
!Subtarget->isTargetIOS() &&
>       !Subtarget->isTargetWatchOS()) {
>     const auto &E = Subtarget->getTargetTriple().getEnvironment();
>
>     bool IsHFTarget = E == Triple::EABIHF || E == Triple::GNUEABIHF ||
>                       E == Triple::MuslEABIHF;
>     // Windows is a special case.  Technically, we will replace all of 
> the "GNU"
>     // calls with calls to MSVCRT if appropriate and adjust the calling
>     // convention then.
>     IsHFTarget = IsHFTarget || Subtarget->isTargetWindows();
>
>     for (int LCID = 0; LCID < RTLIB::UNKNOWN_LIBCALL; ++LCID)
> setLibcallCallingConv(static_cast<RTLIB::Libcall>(LCID),
>                             IsHFTarget ? CallingConv::ARM_AAPCS_VFP
>                                        : CallingConv::ARM_AAPCS);
>   }
>
> IsHFTarget is only true if the target is eabihf. -msoft-abi is 
> completely ignored.
>
> cheers,
>
> Peter
>
> Am 30.03.2017 um 00:15 schrieb Renato Golin:
>> 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
>>
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

Hi Peter,

Sorry, I completely missed this reply. Peter (Smith) is looking into
it, so copying him, here.

I remember too many hacks to Clang's driver to understand all the
nuances between the flags to copy GCC bug-for-bug. We've done it
mostly because the solution space is gigantic and too many (external)
people rely on those bugs being there or the hackery they have won't
work.

I have always been a strong supporter to clean up GCC bug
implementations and be candid (but helpful) to the users to help them
migrate to a decent scheme (and ultimately fix GCC).

Hopefully, we'll have now enough people looking into it that we can
get at least some of that cleaned up.

cheers,
--renato

PS: Also adding Joerg, because he has some weird cases on his own.

On 31 March 2017 at 00:12, Peter Jakubek <pjak at gmx.de>
wrote:
> I think the problem is here:
>
> llvm\lib\Target\ARM\ARMISelLowering.cpp, line 187:
>
>   if (!Subtarget->isTargetDarwin() &&
!Subtarget->isTargetIOS() &&
>       !Subtarget->isTargetWatchOS()) {
>     const auto &E = Subtarget->getTargetTriple().getEnvironment();
>
>     bool IsHFTarget = E == Triple::EABIHF || E == Triple::GNUEABIHF ||
>                       E == Triple::MuslEABIHF;
>     // Windows is a special case.  Technically, we will replace all of the
> "GNU"
>     // calls with calls to MSVCRT if appropriate and adjust the calling
>     // convention then.
>     IsHFTarget = IsHFTarget || Subtarget->isTargetWindows();
>
>     for (int LCID = 0; LCID < RTLIB::UNKNOWN_LIBCALL; ++LCID)
>       setLibcallCallingConv(static_cast<RTLIB::Libcall>(LCID),
>                             IsHFTarget ? CallingConv::ARM_AAPCS_VFP
>                                        : CallingConv::ARM_AAPCS);
>   }
>
> IsHFTarget is only true if the target is eabihf. -msoft-abi is completely
> ignored.
>
> cheers,
>
> Peter
>
> Am 30.03.2017 um 00:15 schrieb Renato Golin:
>>
>> 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
>>
>