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 via email to