[clang][DFP] Add __attribute__((mode(*D))) support for declaring decimal floating-point types.

[tahonermann]

Current proposals for supporting decimal floating-point (DFP) types in C++, e.g., ISO/IEC TR 24733:2011, do not specify keywords to be used as type specifiers. Rather, DFP types are specified as standard library types that, in practice, wrap a builtin type that is not otherwise exposed with a simple name. Gcc enables builtin DFP types to be declared using the GNU mode attribute as follows:

• float __attribute__((mode(SD))) // _Decimal32
• float __attribute__((mode(DD))) // _Decimal64
• float __attribute__((mode(TD))) // _Decimal128
  This change implements support for these additional machine modes.

This change also extends several of the clang::Type AST node attributes to include DFP types in addition to other floating-point types. These extensions match extensions to terms of the same name made in C23. The directly affected predicates includes:

• Type::isRealFloatingType()
• Type::isFloatingType()
• Type::isRealType()
• Type::isArithmeticType()
  The following new predicate can be used to differentiate DFP types where needed.
• Type::isDecimalFloatingType()

The existing DFP specifications, including C23, do not include support for complex DFP types. Gcc does not provide such support either. These changes follow that existing precedent and do not enable support for complex DFP types as well. However, vector types are allowed to have DFP types as their element type.

[AaronBallman]

Are there targets for which we don't expect to support DFP? e.g., should we be messing with TargetInfo up front to test whether the target supports the feature?

Given that the C names are in the reserved namespace, should we consider exposing them in C++ directly even though there's an expectation of getting a library type eventually? (I'm wary of a design where _Decimal32 is expected to be ABI compatible with std::decimal<32> or however it's spelled as a library type. Otherwise, extern declarations to C declarations get very, very weird. e.g.,

// Exported from some user library
void func(_Decimal32 val);

// Some C++ .cpp file, not including the .h file
extern void func(std::decimal<32> val); // Trust that this is ABI compatible.

Also, remember to update user-facing documentation for the extension. We should probably be more clear about what from Annex F and Annex H we do and don't support, as part of that documentation effort (at least get a framework in place so others can continue to update).

[tahonermann]

Are there targets for which we don't expect to support DFP? e.g., should we be messing with TargetInfo up front to test whether the target supports the feature?

Yes, there will be targets that we won't be able to provide DFP support for; at least for quite some time to come. Changes to TargetInfo and friends are in the next patch I'll be posting.

Given that the C names are in the reserved namespace, should we consider exposing them in C++ directly even though there's an expectation of getting a library type eventually? (I'm wary of a design where _Decimal32 is expected to be ABI compatible with std::decimal<32> or however it's spelled as a library type. Otherwise, extern declarations to C declarations get very, very weird. e.g.,

I've been thinking about that as well. Since gcc doesn't expose the keywords, I'm worried about interfering with users adding their own typedefs for compatibility.

ABI compatibility between the scalar and library types is required by the Itanium ABI. See 3.1.2.4 (Parameters of Special Class Type), 3.1.3.2 (Return Values of Special Class Type), and 5.1.5.5 (Class, union, and enum types).

Also, remember to update user-facing documentation for the extension. We should probably be more clear about what from Annex F and Annex H we do and don't support, as part of that documentation effort (at least get a framework in place so others can continue to update).

Yes, I filed issue #24 to keep tabs on needed documentation updates.

[zahiraam]

Looks good. Thanks.

[shafik]

LGTM modulo discussion on whether dfp should really be treated as integer types internally.

[shafik]

As discussed offline, I found codegen and lowering much simpler if we treated this like fixed point and acted as if it was a signed integer type. We may want to revisit this once we get to those tasks.

[tahonermann]

Oh, neat, this comment survived the branch rebasing! Maybe all is not lost with respect to stacking and rebasing PRs!

I agree we may want to revisit this, but I think we should try to be consistent with the standard until we have a good indication that doing so isn't working in practice. It might make sense to introduce an isBinaryFloatingPoint() predicate and switch most existing uses of isFloatingPoint() (~330 uses) to it. Likewise for isFloatingType (~85 uses). I hope there won't be incentive to do similarly for isRealType() (~12 uses), isRealFloatingType() (~100 uses), and isArithmeticType() (~40 uses).