An asm constraint issue (ARM FPU)

[Marc Glisse]

On Sun, 25 Jul 2021, Zoltán Kócsi wrote:

> I try to write a one-liner inline function to create a double form
> a 64-bit integer, not converting it to a double but the integer
> containing the bit pattern for the double (type spoofing).
>
> The compiler is arm-eabi-gcc 8.2.0.
> The target is a Cortex-A9, with NEON.
>
> According to the info page the assembler constraint "w" denotes an FPU
> double register, d0 - d31.
>
> The code is the following:
>
> double spoof( uint64_t x )
> {
> double r;
>
>   asm volatile
>   (
>     " vmov.64 %[d],%Q[i],%R[i] \n"

Isn't it supposed to be %P[d] for a double?
(the documentation is very lacking...)

>     : [d] "=w" (r)
>     : [i] "q" (x)
>   );
>
>   return r;
> }
>
> The command line:
>
> arm-eabi-gcc -O0 -c -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=neon-vfpv4 \
> test.c
>
> It compiles and the generated object code is this:
>
> 00000000 <spoof>:
>   0:   e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
>   4:   e28db000        add     fp, sp, #0
>   8:   e24dd014        sub     sp, sp, #20
>   c:   e14b01f4        strd    r0, [fp, #-20]  ; 0xffffffec
>  10:   e14b21d4        ldrd    r2, [fp, #-20]  ; 0xffffffec
>  14:   ec432b30        vmov    d16, r2, r3
>  18:   ed4b0b03        vstr    d16, [fp, #-12]
>  1c:   e14b20dc        ldrd    r2, [fp, #-12]
>  20:   ec432b30        vmov    d16, r2, r3
>  24:   eeb00b60        vmov.f64        d0, d16
>  28:   e28bd000        add     sp, fp, #0
>  2c:   e49db004        pop     {fp}            ; (ldr fp, [sp], #4)
>  30:   e12fff1e        bx      lr
>
> which is not really efficient, but works.
>
> However, if I specify -O1, -O2 or -Os then the compilation fails
> because assembler complains. This is the assembly the compiler
> generated, (comments and irrelevant stuff removed):
>
> spoof:
>   vmov.64 s0,r0,r1
>   bx lr
>
> where the problem is that 's0' is a single-precision float register and
> it should be 'd0' instead.
>
> Either I'm seriously missing something, in which case I would be most
> obliged if someone sent me to the right direction; or it is a compiler
> or documentation bug.
>
> Thanks,
>
> Zoltan

-- 
Marc Glisse