[Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC.

[Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC.

[Jacob.Bramley at arm dot com]

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.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[joseph at codesourcery dot com]

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.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[siarhei.siamashka at gmail dot com]

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.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[ibolton at gcc dot gnu.org]

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.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[Jacob.Bramley at arm dot com]

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.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[rearnsha at gcc dot gnu.org]

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...

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[siarhei.siamashka at gmail dot com]

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.