Decimal float impl

[shafik]

This is basis for some discussions about APDecimalFloat, APDecimalFloatLiteral, APDecimalFloatStorage and DecimalFloatExprEvaluator as well as support classes.

You will see that I made the type as integer type because during codegen I could not get it to work any other way. I spent a while trying to disentangle a way to make it work otherwise without success. Floating point type seems to be deeply embedded in the codegen and taking the same path FixedPoint took felt like a much easier row.

There is a lot of hacky code to get the intel decimal float library integrated and you can see in some of the reading of decimal float literals and math I am using the library. You can see that underneath the type used for BID are all integral types.

I could compile code like this:

#include <stdio.h>

void f(_Decimal32 x ) {

}

int main() {
  const _Decimal32 x = 1.0df;
  const _Decimal32 y = 2.0df;
  const _Decimal32 z = x;

  1.0df;

  //static const int ix = 1 + 2;
  static const _Decimal32 a = 1.0df + 2.0df;

  //f(x);

  //x && y;

  //x * y;
  printf("Add\n");
  x - y;

  printf("Sub\n");
  x + y;

  _Decimal32 x2 = 1.0df;
  _Decimal32 y2 = 2.0df;

}

and dump the ast:

-FunctionDecl 0x12e9361b0 <line:7:1, line:31:1> line:7:5 main 'int ()'
  `-CompoundStmt 0x12e936b20 <col:12, line:31:1>
    |-DeclStmt 0x12e936300 <line:8:3, col:29>
    | `-VarDecl 0x12e936268 <col:3, col:24> col:20 used x 'const _Decimal32' cinit
    |   `-DecimalFloatLiteral 0x12e9362d0 <col:24> '_Decimal32' +10E-1
    |-DeclStmt 0x12e9363c0 <line:9:3, col:29>
    | `-VarDecl 0x12e936328 <col:3, col:24> col:20 used y 'const _Decimal32' cinit
    |   `-DecimalFloatLiteral 0x12e936390 <col:24> '_Decimal32' +20E-1
    |-DeclStmt 0x12e936488 <line:10:3, col:25>
    | `-VarDecl 0x12e9363e8 <col:3, col:24> col:20 z 'const _Decimal32' cinit
    |   `-ImplicitCastExpr 0x12e936470 <col:24> '_Decimal32' <LValueToRValue>
    |     `-DeclRefExpr 0x12e936450 <col:24> 'const _Decimal32' lvalue Var 0x12e936268 'x' 'const _Decimal32'
    |-DecimalFloatLiteral 0x12e9364a0 <line:12:3> '_Decimal32' +10E-1
    |-DeclStmt 0x12e9365c8 <line:15:3, col:44>
    | `-VarDecl 0x12e9364e0 <col:3, col:39> col:27 a 'const _Decimal32' static cinit
    |   `-BinaryOperator 0x12e9365a8 <col:31, col:39> '_Decimal32' '+'
    |     |-DecimalFloatLiteral 0x12e936548 <col:31> '_Decimal32' +10E-1
    |     `-DecimalFloatLiteral 0x12e936578 <col:39> '_Decimal32' +20E-1
    |-CallExpr 0x12e9366b0 <line:22:3, col:17> 'int'
    | |-ImplicitCastExpr 0x12e936698 <col:3> 'int (*)(const char *, ...)' <FunctionToPointerDecay>
    | | `-DeclRefExpr 0x12e9365e0 <col:3> 'int (const char *, ...)' Function 0x12e92dcd8 'printf' 'int (const char *, ...)'
    | `-ImplicitCastExpr 0x12e9366f0 <col:10> 'const char *' <NoOp>
    |   `-ImplicitCastExpr 0x12e9366d8 <col:10> 'char *' <ArrayToPointerDecay>
    |     `-StringLiteral 0x12e936638 <col:10> 'char[5]' lvalue "Add\n"
    |-BinaryOperator 0x12e936778 <line:23:3, col:7> '_Decimal32' '-'
    | |-ImplicitCastExpr 0x12e936748 <col:3> '_Decimal32' <LValueToRValue>
    | | `-DeclRefExpr 0x12e936708 <col:3> 'const _Decimal32' lvalue Var 0x12e936268 'x' 'const _Decimal32'
    | `-ImplicitCastExpr 0x12e936760 <col:7> '_Decimal32' <LValueToRValue>
    |   `-DeclRefExpr 0x12e936728 <col:7> 'const _Decimal32' lvalue Var 0x12e936328 'y' 'const _Decimal32'
    |-CallExpr 0x12e9368b8 <line:25:3, col:17> 'int'
    | |-ImplicitCastExpr 0x12e9368a0 <col:3> 'int (*)(const char *, ...)' <FunctionToPointerDecay>
    | | `-DeclRefExpr 0x12e936848 <col:3> 'int (const char *, ...)' Function 0x12e92dcd8 'printf' 'int (const char *, ...)'
    | `-ImplicitCastExpr 0x12e9368f8 <col:10> 'const char *' <NoOp>
    |   `-ImplicitCastExpr 0x12e9368e0 <col:10> 'char *' <ArrayToPointerDecay>
    |     `-StringLiteral 0x12e936868 <col:10> 'char[5]' lvalue "Sub\n"
    |-BinaryOperator 0x12e936980 <line:26:3, col:7> '_Decimal32' '+'
    | |-ImplicitCastExpr 0x12e936950 <col:3> '_Decimal32' <LValueToRValue>
    | | `-DeclRefExpr 0x12e936910 <col:3> 'const _Decimal32' lvalue Var 0x12e936268 'x' 'const _Decimal32'
    | `-ImplicitCastExpr 0x12e936968 <col:7> '_Decimal32' <LValueToRValue>
    |   `-DeclRefExpr 0x12e936930 <col:7> 'const _Decimal32' lvalue Var 0x12e936328 'y' 'const _Decimal32'
    |-DeclStmt 0x12e936a48 <line:28:3, col:24>
    | `-VarDecl 0x12e9369b0 <col:3, col:19> col:14 x2 '_Decimal32' cinit
    |   `-DecimalFloatLiteral 0x12e936a18 <col:19> '_Decimal32' +10E-1
    `-DeclStmt 0x12e936b08 <line:29:3, col:24>
      `-VarDecl 0x12e936a70 <col:3, col:19> col:14 y2 '_Decimal32' cinit
        `-DecimalFloatLiteral 0x12e936ad8 <col:19> '_Decimal32' +20E-1

[zahiraam]

unrelated change. The one below too.

[zahiraam]

No need for this anymore, right? Same below.

[zahiraam]

Do we need to have width to be default?

[zahiraam]

We will need here get/set scale too.

[zahiraam]

I made a first pass through the patch, mostly looking at APDecimalFloat and decFltSemantics and this seems to be moving in the right direction. I think using the integer type is the way to go. This is also the way ICC implements it.

For the arithmetic operations I suppose we would need to have the 64 and 128 flavors for them, right?

[tahonermann]

I got about half way through the changes today. Overall, the direction looks good to me; I'm just finding more nit-picky detail concerns.

[tahonermann]

Per https://llvm.org/docs/CodingStandards.html#source-code-width, limit line length to 80 characters.

[tahonermann]

The change to this comment doesn't seem right.

[tahonermann]

The example cast operations in the comments are still for fixed point types and should be switched to operations on DFP types and literals.

[tahonermann]

Suggested change

	/// Return true if this is a decinal float or integer type.
	/// Return true if this is a decimal float or integer type.

[tahonermann]

Do we need to worry about the availability of 128-bit integer support here? I don't think that concern exists for fixed-point types.

[tahonermann]

The referenced diagnostic is for fixed-point, so we presumably need to use the right one (if one for DFP already exists), introduce a new one or, if the existing one is sufficiently generic, rename it. Additional occurrences can be found below.

[tahonermann]

The literal value will need to be mangled here as well; not just the type. See https://godbolt.org/z/Yd8a9ofGn for an example (and a chance to chuckle at the icc behavior).

[tahonermann]

Mangling of the value will be necessary here as well. See https://godbolt.org/z/3Edvh7xa4.

[tahonermann]

I think DFP types should be considered scalar types; the check for isScalarType() should therefore suffice here.

(note for myself: this is as far as I got with review before running out of time for the day)

[tahonermann]

I completed my first pass through all of the changes.

I need to spend some time looking at APFloat before weighing in on whether we should try using it first before concluding that an APDecimalFloat is needed. Likewise for fltSemantics vs decFltSemantics.

If you haven't already, can you think about how we can break this up into smaller, but still logically contained, reviews?

[tahonermann]

Suggested change

	DecimalFloat64Width = 64;
	DecimalFloat64Align = 64;
	DecimalFloat128Width = 128;
	DecimalFloat64Width = 64;
	DecimalFloat64Align = 64;
	DecimalFloat128Width = 128;

Indentation is off.

[tahonermann]

Suggested change

	Encoding = llvm::dwarf::DW_ATE_unsigned;
	Encoding = llvm::dwarf::DW_ATE_decimal_float;

The DWARF specification already defines an encoding value for the IEEE 754R DFP types and an identifier is present in llvm/include/llvm/BinaryFormat/Dwarf.def, so we can set the right encoding now. I'm not sure if differentiation is required for BID vs DPD encoding here, but we can revisit that as part of tahonermann#20 later.

[tahonermann]

I think we need to use getAs() instead of dyn_cast() to look through sugared types like TypedefType. Or do I have that backwards?

[tahonermann]

If I'm reading the code right, this will return a llvm::ConstantInt and thereby lose track of the fact that the value corresponds to a DFP representation. Do we not need to keep track of that somehow so that the constant value gets associated with a DFP IR type? That seems important if we're going to utilize the fadd IR instruction/operator.

[tahonermann]

s/Fixed/Decimal/ throughout.

[tahonermann]

This will presumably need to be generalized for 64-bit and 128-bit literal support.

[tahonermann]

Suggested change

	// S.Diag(DS.getTypeSpecTypeLoc(), diag::err_decimal_unsupported);
	// Result = Context.IntTy;
	// declarator.setInvalidType(true);

Remove.

[tahonermann]

Zahira added a isDecimalFloatingPointTy() that can be used here.

[tahonermann]

This will presumably need to be generalized for 64-bit and 128-bit support.

[tahonermann]

I think we can omit the saturation properties; we don't need to worry about saturating and non-saturating types like fixed-point does.