-
Notifications
You must be signed in to change notification settings - Fork 1
[DFP] Implement parsing of Decimal32 literals and printing of Decimal32 values #49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dfp
Are you sure you want to change the base?
Conversation
This change starts the base set of changes to support DFP in APFloat and allow us to parse a DFP decalration and examine the AST. Since we don't have a DFP implementation I avoided implementating much beyond the basics for APFloat.
This currently only supports Decimal32 literals.
…hafik_dfp_parse_literals
You may notice that I replaced |
llvm_unreachable("Unknow DFP semantics"); | ||
} | ||
|
||
void DFPFloat::mul64By64To128(DFPFloat::Two64Wrapped &p, uint64_t cx, uint64_t cy) const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of this could could benefit from using utilities in MathExtras.h
…hafik_dfp_parse_literals
to support DFP have exposed bugs. The current version should now properly dispathc for DoubleAPFloat, IEEEFloat and DFPFloat.
Just applied a fix to |
This PR implements the parsing and printing of
Decimal32
literals.A large part of the work was weaving through the existing
APFloat
code paths for parsing and printing of literals. The rest of the work was generalizing it so that we have paths for 32, 64 and 128.Since the delta was getting large I limited this change to only dealing with
Decimal32
and will implement similar code forDecimal64
andDecimal128
in a follow-up PR.The parsing and printing code is port of the code from the Intel DFP library. I imported the tables as they were. I don't think there is an obvious optimization around these and it would likely be a lot of work and so I feel we should leave these as are for the first implementation and if we find issue we can revisit at that time.