[PATCH] Allow encoded 8-bit floating point constants in ARM vmov instructions
renato.golin at linaro.org
Thu Dec 19 07:09:48 PST 2013
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
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.
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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits