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.