From: Marc Glisse <marc.glisse@inria.fr>
To: "Zoltán Kócsi" <zoltan@bendor.com.au>
Cc: gcc@gcc.gnu.org
Subject: Re: An asm constraint issue (ARM FPU)
Date: Sun, 25 Jul 2021 14:19:56 +0200 (CEST) [thread overview]
Message-ID: <9bd5681-fd38-7883-e06d-ca1c6b754a0@hippo.saclay.inria.fr> (raw)
In-Reply-To: <20210725123616.45126a97@mazsola>
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
next prev parent reply other threads:[~2021-07-25 12:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-25 2:36 Zoltán Kócsi
2021-07-25 12:19 ` Marc Glisse [this message]
2021-07-29 21:26 ` Zoltán Kócsi
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=9bd5681-fd38-7883-e06d-ca1c6b754a0@hippo.saclay.inria.fr \
--to=marc.glisse@inria.fr \
--cc=gcc@gcc.gnu.org \
--cc=zoltan@bendor.com.au \
/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).