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.
next prev parent 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: linkBe 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).