Luke Cheeseman via llvm-dev
2015-Sep-08 15:04 UTC
[llvm-dev] LLVM-MC: parsing and handling floats
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>
Luke Cheeseman via llvm-dev
2015-Sep-17 11:49 UTC
[llvm-dev] LLVM-MC: parsing and handling floats
Hello, Just a ping on this to see if there is any interest on making these kinds of changes to MC and any suggestions on such, I also attach and updated patch which fixes a bug in the previous patch. The bug was due to trying to emit the float to an object file which has been patched. This was exposed when you tried to assign a variable a float value, I'm not sure what the best thing to do in this case is so for now it emits a warning that the float is parsed to quadruple precision. I've also added some tests to MC/AsmParser/exprs.s to demonstrate the changes in use. Thanks, Luke Cheeseman From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Luke Cheeseman via llvm-dev Sent: 08 September 2015 16:05 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] LLVM-MC: parsing and handling floats 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 parsed 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150917/d45fa976/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: parser_floats.patch Type: application/octet-stream Size: 57874 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150917/d45fa976/attachment.obj>