Re: [PATCH][ARM][RFC] PR target/65578 Fix gcc.dg/torture/stackalign/builtin-apply-4.c for single-precision fpus

[Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>]

Ping*4.

Thanks,
Kyrill
On 02/03/16 13:46, Kyrill Tkachov wrote:
> Ping*3.
>
> Thanks,
> Kyrill
> On 24/02/16 13:48, Kyrill Tkachov wrote:
>> Ping*2
>>
>> Thanks,
>> Kyrill
>>
>> On 17/02/16 10:12, Kyrill Tkachov wrote:
>>> Ping.
>>> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00634.html
>>>
>>> As mentioned before, this is actually a fix for PR target/69538.
>>> I got confused when writing the cover letter and ChangeLog...
>>>
>>> Thanks,
>>> Kyrill
>>>
>>> On 09/02/16 17:24, Kyrill Tkachov wrote:
>>>>
>>>> On 09/02/16 17:21, Kyrill Tkachov wrote:
>>>>> Hi all,
>>>>>
>>>>> In this wrong-code PR the builtin-apply-4.c test fails with -flto but only when targeting an fpu
>>>>> with only single-precision capabilities.
>>>>>
>>>>> bar is a function returing a double. For non-LTO compilation the caller of bar reads the return value
>>>>> from it from the s0 and s1 VFP registers like expected, but for -flto the caller seems to expect the
>>>>> return value from the r0 and r1 regs.  The RTL dumps show that too.
>>>>>
>>>>> Debugging the calls to arm_function_value show that in the -flto compilation the function bar is deemed
>>>>> to be a local function call and assigned the ARM_PCS_AAPCS_LOCAL PCS variant, whereas for the non-LTO (and non-breaking)
>>>>> compilation it uses the ARM_PCS_AAPCS_VFP variant.
>>>>>
>>>>> Further down in use_vfp_abi when deciding whether to use VFP registers for the result there is a bit of
>>>>> logic that rejects VFP registers when handling the ARM_PCS_AAPCS_LOCAL variant with a double precision value
>>>>> on an FPU that is not TARGET_VFP_DOUBLE.
>>>>>
>>>>> This seems wrong for ARM_PCS_AAPCS_LOCAL to me. ARM_PCS_AAPCS_LOCAL means that the function doesn't escape
>>>>> the translation unit and we can thus use whatever variant we want. From what I understand we want to use the
>>>>> VFP regs when possible for FP values.
>>>>>
>>>>> So this patch removes that restriction and for the testcase the caller of bar correctly reads the return
>>>>> value of bar from the VFP registers and everything works.
>>>>>
>>>>> This patch has been bootstrapped and tested on arm-none-linux-gnueabihf configured with --with-fpu=fpv4-sp-d16.
>>>>> The bootstrapped was performed with LTO.
>>>>> I didn't see any regressions.
>>>>>
>>>>> It seems that this logic was put there in 2009 with r154034 as part of a large patch to enable support for half-precision
>>>>> floating point.
>>>>>
>>>>> I'm not very familiar with this part of the code, so is this a safe patch to do?
>>>>> The patch should only ever change behaviour for single-precision-only fpus and only for static functions
>>>>> that don't get called outside their translation units (or during LTO I suppose) so there shouldn't
>>>>> be any ABI problems, I think.
>>>>>
>>>>> Is this ok for trunk?
>>>>>
>>>>> Thanks,
>>>>> Kyrill
>>>>>
>>>>
>>>> Huh, I just realised I wrote completely the wrong PR number on this.
>>>> The PR I'm talking about here is PR target/69538
>>>>
>>>> Sorry for the confusion.
>>>>
>>>> Kyrill
>>>>
>>>>
>>>>> 2016-02-09 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>>>>>
>>>>>     PR target/65578
>>>>>     * config/arm/arm.c (use_vfp_abi): Remove id_double argument.
>>>>>     Don't check for is_double and TARGET_VFP_DOUBLE.
>>>>>     (aapcs_vfp_is_call_or_return_candidate): Update callsite.
>>>>>     (aapcs_vfp_is_return_candidate): Likewise.
>>>>>     (aapcs_vfp_is_call_candidate): Likewise.
>>>>>     (aapcs_vfp_allocate_return_reg): Likewise.
>>>>
>>>
>>
>