<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 December 2013 19:47, David Peixotto <span dir="ltr"><<a href="mailto:dpeixott@codeaurora.org" target="_blank">dpeixott@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">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.</span></div>
</blockquote><div><br></div><div>Ahn, true. Sorry, I got lost in the way, and mixed some of the context of this thread with the VMLA thread...</div><div><br></div><div>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.</div>
<div><br></div><div>FCONSTD:</div><div><a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CJAEFGHE.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CJAEFGHE.html</a><br>
</div><div><br></div><div>VMOV.F:</div><div><a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/CJAEFGHE.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/CJAEFGHE.html</a><br>
</div><div><br></div><div>Let me gather the issues...</div><div><br></div><div>1. VMOV.f64 had support for encoded literals, seems accidental, shouldn't have been there. How do we "fix" this?</div><div>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.</div>
<div>3. Adding support for encoded FP in VMOV could create a new range of LLVM extensions, and we don't want that.</div><div>4. Support is already there, we could say we only support encoded FPs if using pre-UAL syntax.</div>
<div><br></div><div>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.</div>
<div><br></div><div>IFF this is possible, AND doesn't bloat the code, I don't mind it being added. Jim might have a different opinion...</div><div><br></div><div>cheers,</div><div>--renato</div></div></div></div>