[PATCH] Allow encoded 8-bit floating point constants in ARM vmov instructions

[Renato Golin]

On 18 December 2013 19:47, David Peixotto <dpeixott at codeaurora.org> wrote:

> I started out by trying to implement support for fconstd, which I defined
> as an alias to vmov.f64. This instruction takes an encoded fp-constant as
> the operand. We already had support for parsing the encoded-fp constant as
> an operand to vmov.f64, but that code was broken from an earlier
> refactoring.
>

Ahn, true. Sorry, I got lost in the way, and mixed some of the context of
this thread with the VMLA thread...

So, FCONSTD does accept encoded floats, but that's a deprecated instruction
and, as Jim said, we should not support it unless it's either impossible
not to, or it's just an alias to a UAL instruction. The current ARM
assembler (and GNU, too) doesn't support encoded floats as immediate values.

FCONSTD:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CJAEFGHE.html

VMOV.F:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/CJAEFGHE.html

Let me gather the issues...

1. VMOV.f64 had support for encoded literals, seems accidental, shouldn't
have been there. How do we "fix" this?
2. FCONSTD is pre-UAL, deprecated, and it's not a direct alias to VMOV.F
(as it supports encoded imm). In theory, we'd say *no* to that.
3. Adding support for encoded FP in VMOV could create a new range of LLVM
extensions, and we don't want that.
4. Support is already there, we could say we only support encoded FPs if
using pre-UAL syntax.

My view is that fixing VMOV's encoded FP wouldn't bloat the code, but would
start a precedent (LLVM extensions). Adding FCONSTD as an alias to VMOV
should be ok, if it did support encoded imms, but we should be able to
explicitly allow encoded values *only* if the instruction is FCONSTD, and
not VMOV.F. That would not add any extension on our part.

IFF this is possible, AND doesn't bloat the code, I don't mind it being
added. Jim might have a different opinion...

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131219/d39265d0/attachment.html>