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

[Luke Cheeseman via llvm-dev]

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>