* [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs
@ 2011-05-27 17:50 Julian Brown
2011-06-02 13:17 ` Paul Brook
2011-06-02 15:35 ` Richard Earnshaw
0 siblings, 2 replies; 6+ messages in thread
From: Julian Brown @ 2011-05-27 17:50 UTC (permalink / raw)
To: gcc-patches; +Cc: paul, rearnsha, Ramana Radhakrishnan
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
The helper functions used to implement double-precision arithmetic on
ARM processors that only support single-precision arithmetic in hardware
should use the soft-float ABI (i.e. passing and returning floating-point
arguments in core registers), even when -mfloat-abi=hard is in effect.
This patch tweaks the ABI for the affected functions so that is true.
Tested with cross to ARM EABI, and by manually observing compiler
output. We've also been carrying this patch in our local tree for some
time without issue.
OK to apply?
Thanks,
Julian
ChangeLog
gcc/
* config/arm/arm.c (arm_libcall_uses_aapcs_base)
(arm_init_cumulative_args): Use correct ABI for double-precision
helper functions in hard-float mode if only single-precision
arithmetic is supported in hardware.
[-- Attachment #2: hard-float-double-prec-abi-fix-2.diff --]
[-- Type: text/x-patch, Size: 3551 bytes --]
commit 829dab1d743604e6025b929be7287c3215a57d21
Author: Julian Brown <julian@henry8.codesourcery.com>
Date: Fri May 27 04:49:33 2011 -0700
Fix hard-float ABI for double-precision helpers on single-precision CPUs.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 5a62802..47fba2c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3472,6 +3472,28 @@ arm_libcall_uses_aapcs_base (const_rtx libcall)
convert_optab_libfunc (sfix_optab, DImode, SFmode));
add_libcall (libcall_htab,
convert_optab_libfunc (ufix_optab, DImode, SFmode));
+
+ /* Values from double-precision helper functions are returned in core
+ registers if the selected core only supports single-precision
+ arithmetic, even if we are using the hard-float ABI. */
+ if (TARGET_VFP)
+ {
+ add_libcall (libcall_htab, optab_libfunc (add_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (sdiv_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (smul_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (neg_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (sub_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (eq_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (lt_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (le_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (ge_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (gt_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (unord_optab, DFmode));
+ add_libcall (libcall_htab,
+ convert_optab_libfunc (sext_optab, DFmode, SFmode));
+ add_libcall (libcall_htab,
+ convert_optab_libfunc (trunc_optab, SFmode, DFmode));
+ }
}
return libcall && htab_find (libcall_htab, libcall) != NULL;
@@ -4438,6 +4460,31 @@ arm_init_cumulative_args (CUMULATIVE_ARGS *pcum, tree fntype,
if (arm_libcall_uses_aapcs_base (libname))
pcum->pcs_variant = ARM_PCS_AAPCS;
+ /* We must pass arguments to double-precision helper functions in core
+ registers if we only have hardware support for single-precision
+ arithmetic, even if we are using the hard-float ABI. */
+ if (TARGET_VFP
+ && (rtx_equal_p (libname, optab_libfunc (add_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (sdiv_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (smul_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (neg_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (sub_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (eq_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (lt_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (le_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (ge_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (gt_optab, DFmode))
+ || rtx_equal_p (libname, optab_libfunc (unord_optab, DFmode))
+ || rtx_equal_p (libname, convert_optab_libfunc (sext_optab,
+ DFmode, SFmode))
+ || rtx_equal_p (libname, convert_optab_libfunc (trunc_optab,
+ SFmode, DFmode))
+ || rtx_equal_p (libname, convert_optab_libfunc (sfix_optab,
+ SImode, DFmode))
+ || rtx_equal_p (libname, convert_optab_libfunc (ufix_optab,
+ SImode, DFmode))))
+ pcum->pcs_variant = ARM_PCS_AAPCS;
+
pcum->aapcs_ncrn = pcum->aapcs_next_ncrn = 0;
pcum->aapcs_reg = NULL_RTX;
pcum->aapcs_partial = 0;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs
2011-05-27 17:50 [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs Julian Brown
@ 2011-06-02 13:17 ` Paul Brook
2011-06-02 15:35 ` Richard Earnshaw
1 sibling, 0 replies; 6+ messages in thread
From: Paul Brook @ 2011-06-02 13:17 UTC (permalink / raw)
To: Julian Brown; +Cc: gcc-patches, rearnsha, Ramana Radhakrishnan
> gcc/
> * config/arm/arm.c (arm_libcall_uses_aapcs_base)
> (arm_init_cumulative_args): Use correct ABI for double-precision
> helper functions in hard-float mode if only single-precision
> arithmetic is supported in hardware.
Ok, though I'd add a bit more explanation to the comments: Technically the
same is true for the single precision helpers. However all targets that
support the hard-float ABI implement single-precision in hardware, so this
never occurs in practice.
Paul
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs
2011-05-27 17:50 [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs Julian Brown
2011-06-02 13:17 ` Paul Brook
@ 2011-06-02 15:35 ` Richard Earnshaw
2011-06-03 17:41 ` Julian Brown
1 sibling, 1 reply; 6+ messages in thread
From: Richard Earnshaw @ 2011-06-02 15:35 UTC (permalink / raw)
To: Julian Brown; +Cc: gcc-patches, paul, Ramana Radhakrishnan
On Fri, 2011-05-27 at 17:32 +0100, Julian Brown wrote:
> The helper functions used to implement double-precision arithmetic on
> ARM processors that only support single-precision arithmetic in hardware
> should use the soft-float ABI (i.e. passing and returning floating-point
> arguments in core registers), even when -mfloat-abi=hard is in effect.
> This patch tweaks the ABI for the affected functions so that is true.
>
> Tested with cross to ARM EABI, and by manually observing compiler
> output. We've also been carrying this patch in our local tree for some
> time without issue.
>
> OK to apply?
>
> Thanks,
>
> Julian
>
> ChangeLog
>
> gcc/
> * config/arm/arm.c (arm_libcall_uses_aapcs_base)
> (arm_init_cumulative_args): Use correct ABI for double-precision
> helper functions in hard-float mode if only single-precision
> arithmetic is supported in hardware.
I see Paul has already approved this, but I've just spotted one
potential problem that might cause latent bugs sometime in the future.
The code to register the libcalls is only run once, the first time we
try to look up a libcall. If we ever end up allowing dynamic changing
of CPU and optimization options, not registering the other libcalls will
lead to subtle problems at run time. I suggest that these functions be
unconditionally added along with the other libcalls.
I also don't understand why all the tests are needed in
arm_init_cumulative_args? Surely arm_libcall_uses_aapcs_base() will
already have run that test.
R.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs
2011-06-02 15:35 ` Richard Earnshaw
@ 2011-06-03 17:41 ` Julian Brown
2011-06-06 16:07 ` Richard Earnshaw
2011-06-14 4:09 ` Ramana Radhakrishnan
0 siblings, 2 replies; 6+ messages in thread
From: Julian Brown @ 2011-06-03 17:41 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: gcc-patches, paul, Ramana Radhakrishnan
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On Thu, 02 Jun 2011 16:35:01 +0100
Richard Earnshaw <rearnsha@arm.com> wrote:
> I see Paul has already approved this, but I've just spotted one
> potential problem that might cause latent bugs sometime in the future.
>
> The code to register the libcalls is only run once, the first time we
> try to look up a libcall. If we ever end up allowing dynamic changing
> of CPU and optimization options, not registering the other libcalls
> will lead to subtle problems at run time. I suggest that these
> functions be unconditionally added along with the other libcalls.
Done.
> I also don't understand why all the tests are needed in
> arm_init_cumulative_args? Surely arm_libcall_uses_aapcs_base() will
> already have run that test.
I did some archaeology to try to figure out why things were like that
(the patch was written a while ago) -- and yeah, it looks like it's
completely unnecessary to have those tests in arm_init_cumulative_args.
That bit of code was refactored a while ago, and it looks like the
patch wasn't ever updated properly. My mistake!
I'm re-testing the attached version.
Thanks,
Julian
ChangeLog
gcc/
* config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI
for double-precision helper functions in hard-float mode if only
single-precision arithmetic is supported in hardware.
[-- Attachment #2: hard-float-double-prec-abi-fix-3.diff --]
[-- Type: text/x-patch, Size: 1990 bytes --]
commit 8084eeee248e648e3276b91a957f667c299f84e1
Author: Julian Brown <julian@henry7.codesourcery.com>
Date: Fri Jun 3 04:34:23 2011 -0700
VFP ABI fix for double-precision helpers on single-only processors.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 057f9ba..a1d009b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3345,6 +3345,28 @@ arm_libcall_uses_aapcs_base (const_rtx libcall)
convert_optab_libfunc (sfix_optab, DImode, SFmode));
add_libcall (libcall_htab,
convert_optab_libfunc (ufix_optab, DImode, SFmode));
+
+ /* Values from double-precision helper functions are returned in core
+ registers if the selected core only supports single-precision
+ arithmetic, even if we are using the hard-float ABI. The same is
+ true for single-precision helpers, but we will never be using the
+ hard-float ABI on a CPU which doesn't support single-precision
+ operations in hardware. */
+ add_libcall (libcall_htab, optab_libfunc (add_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (sdiv_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (smul_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (neg_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (sub_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (eq_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (lt_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (le_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (ge_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (gt_optab, DFmode));
+ add_libcall (libcall_htab, optab_libfunc (unord_optab, DFmode));
+ add_libcall (libcall_htab, convert_optab_libfunc (sext_optab, DFmode,
+ SFmode));
+ add_libcall (libcall_htab, convert_optab_libfunc (trunc_optab, SFmode,
+ DFmode));
}
return libcall && htab_find (libcall_htab, libcall) != NULL;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs
2011-06-03 17:41 ` Julian Brown
@ 2011-06-06 16:07 ` Richard Earnshaw
2011-06-14 4:09 ` Ramana Radhakrishnan
1 sibling, 0 replies; 6+ messages in thread
From: Richard Earnshaw @ 2011-06-06 16:07 UTC (permalink / raw)
To: Julian Brown; +Cc: gcc-patches, paul, Ramana Radhakrishnan
On 06/03/11 18:41, Julian Brown wrote:
> On Thu, 02 Jun 2011 16:35:01 +0100
> Richard Earnshaw<rearnsha@arm.com> wrote:
>
>
>> I see Paul has already approved this, but I've just spotted one
>> potential problem that might cause latent bugs sometime in the future.
>>
>> The code to register the libcalls is only run once, the first time we
>> try to look up a libcall. If we ever end up allowing dynamic changing
>> of CPU and optimization options, not registering the other libcalls
>> will lead to subtle problems at run time. I suggest that these
>> functions be unconditionally added along with the other libcalls.
>>
> Done.
>
>
>> I also don't understand why all the tests are needed in
>> arm_init_cumulative_args? Surely arm_libcall_uses_aapcs_base() will
>> already have run that test.
>>
> I did some archaeology to try to figure out why things were like that
> (the patch was written a while ago) -- and yeah, it looks like it's
> completely unnecessary to have those tests in arm_init_cumulative_args.
> That bit of code was refactored a while ago, and it looks like the
> patch wasn't ever updated properly. My mistake!
>
> I'm re-testing the attached version.
>
> Thanks,
>
> Julian
>
> ChangeLog
>
> gcc/
> * config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI
> for double-precision helper functions in hard-float mode if only
> single-precision arithmetic is supported in hardware.
OK.
R.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs
2011-06-03 17:41 ` Julian Brown
2011-06-06 16:07 ` Richard Earnshaw
@ 2011-06-14 4:09 ` Ramana Radhakrishnan
1 sibling, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2011-06-14 4:09 UTC (permalink / raw)
To: Julian Brown; +Cc: Richard Earnshaw, gcc-patches, paul
>
> I'm re-testing the attached version.
Shouldn't this be backported to release branches - specifically 4.6
(and 4.5 since this is where TARGET_VFP_SINGLE was introduced) ?
cheers
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-06-14 1:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-27 17:50 [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs Julian Brown
2011-06-02 13:17 ` Paul Brook
2011-06-02 15:35 ` Richard Earnshaw
2011-06-03 17:41 ` Julian Brown
2011-06-06 16:07 ` Richard Earnshaw
2011-06-14 4:09 ` Ramana Radhakrishnan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).