[llvm-dev] LLVM-MC: parsing and handling floats

Luke Cheeseman via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 8 08:04:35 PDT 2015


MC currently parses assembly floats in parseExpression by extracting the string for the Real token and parsing this to a double precision floating point value; this value is then bitcast into an integer and an MCExprConstant is created from this. This has some issues:

*         It isn't possible to determine after parseExpression whether a integer or a floating point value was parsed

*         Instructions which expect an integer and use parse expression allow strange operands as the value becomes bitcast to an integer, for example:

add r0, r0, lsl #4.94065645841246544176568792868E-323

will assemble with llvm-mc -triple armv8

as it is read as

add r0, r0, lsl #10

*         Expressions allow floats and expressions are attempted to be evaluated , any float in an expression gets represented by its integer representation and this gets used when evaluating an expressions

I attach a patch which is an attempt at fixing the above issues by introducing an MCFloatExpr which stores the float value as an APFloat and also by adding an APFloat to MCValue to allow float assembler immediates, this solves the above by:

*         You can determine the type parsed bases on the MCExpr returned

*         As most places already check that value returned is MCConstantExpr it means that the MCFloatExprs are only permitted where they have been added in this patch

o   This prevents the above instruction from being assembled an instead throws the following error:

"error: invalid immediate shift value"

*         The evaluation functions now take an MCValue which can represent either a float or an integer, and the evaluation proceeds based on the type of the value so that float expressions treat the values as floats

o   When the types are mixed I convert the integers to floats and continue, so the overall result will be a float so floats can only be used when expected

I would like some feedback on interest in this patch and changing the way floats are handled and any suggestions and criticisms and whether this is  a good or bad way of approaching this.

Thanks,
Luke Cheeseman


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/ceb389ae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parser_floats.patch
Type: application/octet-stream
Size: 51049 bytes
Desc: parser_floats.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/ceb389ae/attachment-0001.obj>


More information about the llvm-dev mailing list