public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC.
@ 2010-10-22 7:53 Jacob.Bramley at arm dot com
2010-10-22 12:09 ` [Bug target/46128] " joseph at codesourcery dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: Jacob.Bramley at arm dot com @ 2010-10-22 7:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
Summary: There is no mechanism for detecting VFP revisions in
ARM GCC.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: Jacob.Bramley@arm.com
CC: rearnsha@gcc.gnu.org
Target: ARM
There is currently no mechanism for detecting different versions of VFP using
the pre-processor. In C code, this is not a problem, but it is necessary
information when writing in-line assembly code that needs to be portable across
ARM platforms.
As a real-world example, consider the following Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=601914
In that example, Siahei wrote an in-line assembly block that constructs
scripted arguments according to EABI ('hard' variant), then calls the specified
function. However, in order to do this safely, we have to specify all the
scratch registers in the clobber list, including D16-D31. Luckily, it seems
that GCC accepts these in the clobber list even on VFPv3-D16, but will that
always be the case?
More generally, it would be beneficial to be able to optimize routines using
specific VFPv3 instructions (such as VMOV's immediate-operand form), or to make
use of VFPv4's fused-mulitply-accumulate instructions.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
@ 2010-10-22 12:09 ` joseph at codesourcery dot com
2010-10-25 14:44 ` siarhei.siamashka at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: joseph at codesourcery dot com @ 2010-10-22 12:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-22 12:08:57 UTC ---
On Fri, 22 Oct 2010, Jacob.Bramley at arm dot com wrote:
> There is currently no mechanism for detecting different versions of VFP using
> the pre-processor. In C code, this is not a problem, but it is necessary
> information when writing in-line assembly code that needs to be portable across
> ARM platforms.
<http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01654.html> refers to a
"draft ACLE" document as specifying the existing __ARM_PCS and
__ARM_PCS_VFP preprocessor symbols. I haven't seen that document - could
someone post a copy/link? Does it define symbols for VFP versions? If
not, perhaps it should be revised to do so?
> In that example, Siahei wrote an in-line assembly block that constructs
> scripted arguments according to EABI ('hard' variant), then calls the specified
> function. However, in order to do this safely, we have to specify all the
> scratch registers in the clobber list, including D16-D31. Luckily, it seems
> that GCC accepts these in the clobber list even on VFPv3-D16, but will that
> always be the case?
Note that there may be problems clobbering D registers. See bug 43440. I
don't think Richard Earnshaw's patch
<http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00978.html> ever got
reviewed or pinged - it probably needs pinging. (In general, unreviewed
patches are best pinged about weekly.)
> More generally, it would be beneficial to be able to optimize routines using
> specific VFPv3 instructions (such as VMOV's immediate-operand form), or to make
> use of VFPv4's fused-mulitply-accumulate instructions.
For fused multiply-add, the best approach is to describe them in the ARM
.md files using the new fma: RTL facility, so that calls to fma / fmaf /
__builtin_fma / __builtin_fmaf use the instructions automatically as on
other targets whose .md files have been updated like this.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
2010-10-22 12:09 ` [Bug target/46128] " joseph at codesourcery dot com
@ 2010-10-25 14:44 ` siarhei.siamashka at gmail dot com
2010-10-27 12:59 ` ibolton at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: siarhei.siamashka at gmail dot com @ 2010-10-25 14:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
--- Comment #2 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2010-10-25 14:43:52 UTC ---
(In reply to comment #1)
> Note that there may be problems clobbering D registers. See bug 43440. I
> don't think Richard Earnshaw's patch
> <http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00978.html> ever got
> reviewed or pinged - it probably needs pinging. (In general, unreviewed
> patches are best pinged about weekly.)
Yes, that's a very well known bug. But there should be no problems with D
registers, only Q registers are affected.
They say codesourcery already has it fixed (so I assume the patch has been at
least reviewed): http://www.beagleboard.org/irclogs/index.php?date=2010-06-27
# [11:19:58] <ssvb> "raster: check gcc bugzilla -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440"
# [11:19:59] <mru> "the gcc "design" makes it very hard to do this conversion"
# [11:20:01] <raster> "unliek a cpu - gcc can be fixed and updated easily :)"
# [11:20:14] <raster> "mru: seems codesourcery managed it"
> > More generally, it would be beneficial to be able to optimize routines using
> > specific VFPv3 instructions (such as VMOV's immediate-operand form), or to make
> > use of VFPv4's fused-mulitply-accumulate instructions.
>
> For fused multiply-add, the best approach is to describe them in the ARM
> .md files using the new fma: RTL facility, so that calls to fma / fmaf /
> __builtin_fma / __builtin_fmaf use the instructions automatically as on
> other targets whose .md files have been updated like this.
But still there are cases when performance is actually important and
builtins/intrinsics are ruled out because of this. Inline assembly is
convenient because it can be added directly to C sources, without any need to
tweak makefiles or build scripts. This makes inline assembly a good choice for
small non-intrusive performance patches.
Another inconvenience is that in order to check whether for example ARMv6
instructions are supported, one has to use constructs like this (identifiers
fished out from gcc sources):
#if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) || \
defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) || \
defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6T2__) || \
defined(__ARM_ARCH_6M__) || defined(__ARM_ARCH_7__) || \
defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7R__) || \
defined(__ARM_ARCH_7M__)
[...]
#endif
And this is not very maintainable because future gcc versions may introduce
more predefined symbols for newer arm architecture variants. It would be much
nicer if it was possible to just do something like:
#if defined(__arm__) && (__ARM_ARCH__ >= 6)
[...]
#endif
It's basically the same problem as VFP variant identification.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
2010-10-22 12:09 ` [Bug target/46128] " joseph at codesourcery dot com
2010-10-25 14:44 ` siarhei.siamashka at gmail dot com
@ 2010-10-27 12:59 ` ibolton at gcc dot gnu.org
2010-11-03 7:59 ` Jacob.Bramley at arm dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: ibolton at gcc dot gnu.org @ 2010-10-27 12:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
Ian Bolton <ibolton at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2010.10.27 12:59:21
CC| |ibolton at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Ian Bolton <ibolton at gcc dot gnu.org> 2010-10-27 12:59:21 UTC ---
Please complete the "Known to work", "Known to fail", "Version" and "Target
Milestone" and any other useful details you can add. I can then move this onto
the NEW status.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
` (2 preceding siblings ...)
2010-10-27 12:59 ` ibolton at gcc dot gnu.org
@ 2010-11-03 7:59 ` Jacob.Bramley at arm dot com
2010-11-03 10:26 ` rearnsha at gcc dot gnu.org
2012-12-05 0:07 ` siarhei.siamashka at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: Jacob.Bramley at arm dot com @ 2010-11-03 7:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
--- Comment #4 from Jacob Bramley <Jacob.Bramley at arm dot com> 2010-11-03 07:59:30 UTC ---
(In reply to comment #3)
> Please complete the "Known to work", "Known to fail", "Version" and "Target
> Milestone" and any other useful details you can add. I can then move this onto
> the NEW status.
This bug applies to all current versions of GCC, and is a design issue rather
than an implementation issue. I can't fill in "Known to work" and "Known to
fail" because Bugzilla won't accept values such as "All current versions."
The "Target Milestone" is up to you. Sooner is obviously better, but you have
your own priorities, and I don't know anything about the feature-freeze dates
and the like.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
` (3 preceding siblings ...)
2010-11-03 7:59 ` Jacob.Bramley at arm dot com
@ 2010-11-03 10:26 ` rearnsha at gcc dot gnu.org
2012-12-05 0:07 ` siarhei.siamashka at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2010-11-03 10:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Severity|minor |enhancement
--- Comment #5 from Richard Earnshaw <rearnsha at gcc dot gnu.org> 2010-11-03 10:26:11 UTC ---
This is really an enhancement request...
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
` (4 preceding siblings ...)
2010-11-03 10:26 ` rearnsha at gcc dot gnu.org
@ 2012-12-05 0:07 ` siarhei.siamashka at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: siarhei.siamashka at gmail dot com @ 2012-12-05 0:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
--- Comment #6 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-12-05 00:06:39 UTC ---
(In reply to comment #5)
> This is really an enhancement request...
Is there anything that can be done with this enhancement request?
I can see that __ARM_FEATURE_DSP and __ARM_FEATURE_UNALIGNED have been added:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01849.html
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00878.html
This is a step in the right direction, but still not enough.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-12-05 0:07 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-22 7:53 [Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC Jacob.Bramley at arm dot com
2010-10-22 12:09 ` [Bug target/46128] " joseph at codesourcery dot com
2010-10-25 14:44 ` siarhei.siamashka at gmail dot com
2010-10-27 12:59 ` ibolton at gcc dot gnu.org
2010-11-03 7:59 ` Jacob.Bramley at arm dot com
2010-11-03 10:26 ` rearnsha at gcc dot gnu.org
2012-12-05 0:07 ` siarhei.siamashka at gmail dot com
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).