public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
Date: Fri, 22 Oct 2010 12:09:00 -0000	[thread overview]
Message-ID: <20101022120900.3RE2kASPphxd0UCDmxsuBZZbhGNhnKWhKt-kdS81u88@z> (raw)
In-Reply-To: <bug-46128-4@http.gcc.gnu.org/bugzilla/>

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.


  reply	other threads:[~2010-10-22 12:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22  7:53 [Bug target/46128] New: " Jacob.Bramley at arm dot com
2010-10-22 12:09 ` joseph at codesourcery dot com [this message]
2010-10-25 14:44 ` [Bug target/46128] " 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101022120900.3RE2kASPphxd0UCDmxsuBZZbhGNhnKWhKt-kdS81u88@z \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).