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

[David Peixotto]

On 12/18/2013 4:13 AM, Renato Golin wrote:
> On 17 December 2013 21:58, Jim Grosbach <grosbach at apple.com
> <mailto:grosbach at apple.com>> wrote:
>
>     What does the ARM documentation indicate? Either way, you’re right
>     that we should clean up the implementation so that if we reject or
>     accept the different forms of constants, we do so intentionally and
>     not inadvertently.
>
>
> ARM docs mention that both VFPv3+ and NEON VMOV.f32 Rn, #imm support
> encoded floating-point constants. Tables A7-15 and A7-18 (ARMv7-AR):
>
> "The bit pattern represents the floating-point number (–1)S × 2exp ×
> mantissa, where S = UInt(a), exp = UInt(NOT(b):c:d)-3 and mantissa =
> (16+UInt(e:f:g:h))/16."

I tried with both gcc (4.6) and armasm (5.03) and neither accept an 
encoded fp constant (e.g. 0x70) as an operand to vmov.f* instructions.

Interestingly, objdump prints the constant in its encoded form (0x70 
instead of 1.0) so it is not possible to take the objdump output and 
feed it back to the assembler. I checked with llvm-objdump and it prints 
the floating-point value not the encoded value.

It seems our options are:

1. Support encoded fp constants in vmov.f* functions. This option is 
what my current patch does.

2. Explicitly reject encoded fp constants in vmov.f* functions. This 
option amounts to deleting some code in the floating point parsing 
routine and adding an error message.

Which option do you like best?