[llvm-dev] Status regarding support for fixed point numbers (and Embedded-C) in Clang/LLVM (original) (raw)

Francis ANDRE via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 15 07:20:57 PDT 2021

Hello

I would like to mention a deep work of Mike Cowlishaw on decimal arithmetic here: http://speleotrove.com/decimal/#arithmetic/ <http://speleotrove.com/decimal/#arithmetic/>

May be it could bring some different views and improvments from the fixed point numbers (and Embedded-C) in Clang/LLVM

Rgds

Le 15/03/2021 à 13:06, Björn Pettersson A via llvm-dev a écrit :

Status regarding support for fixed point numbers (and Embedded-C) in Clang/LLVM ===============================================================================

During the years there have been a number of questions on cfe-dev and llvm-dev about support for fixed point arithmetic in LLVM. In 2018 Leonard Chan wrote a proposal for adding fixed point number support in clang [1], accompanied by discussions about how to support the types in LLVM [2]. Since then a number of patches has been submitted and nowadays Clang/LLVM has lots of support for fixed point arithmetic, based on the Embedded-C draft [3].

A major part of chapter 4 in [3] should have been implemented by now. Here is a list of features implemented: - Fixed point types can be enabled using the -ffixed-point clang option. - Variables can be declared using the Fract and Accum type specifiers (see for example clang/test/Frontend/fixedpointdeclarations.c for examples). - Saturated fixed point types are available by using the Sat specifier for the Fract and Accum types. - Support for conversion between signed/unsigned fixed-point types and integral or floating point types. - Support for literals, using the following fixed-point suffixes: hr: short Fract uhr: unsigned short Fract r: Fract ur: unsigned Fract lr: long Fract ulr: unsigned long Fract hk: short Accum uhk: unsigned short Accum k: Accum uk: unsigned Accum lk: long Accum ulk: unsigned long Accum - Support for operations involving fixed-point types: Unary (++, --, +, -, !) Binary (+, -, *, /, <<, >>) Comparison (<, <=, >=, >, ==, !=) Assignment / Compound Assignment (=, +=, -=, *=, /=, <<=, >>=) Future improvements: - Improve user documentation (the comment that Fract types aren't supported has been removed from the UsersManual, but we haven't really added anything describing that we now support fixed point types). - Support for format specifiers (r/R/k/K) for fixed-point arguments in I/O functions. - Support for pragmas such as FXFRACTOVERFLOW and FXACCUMOVERFLOW. (This might be a difference compared to what they have implemented in gcc, see [4].) - The Embedded-C draft [3] mentions a stdfix.h library. (This has not been implemented. Also lacking in gcc according to [4].) - Implement sanitizer checks for fixed point shifts. The LLVM IR for shift has UB semantics when shift count is too large. So either we need to clamp shift count when lowering shift operators (if there are special rules for embedded-c), or if it is UB on c level it would be nice if the sanitizer catch such faults. There are some TODO:s left in the code (see for example ScalarExprEmitter::EmitShl) indicating that the fixed point lowering currently bypass the code for sanitizing the shift count. - Add some C++ compatibility. One thing that limits the fixed point support to C is lack of name mangling rules for fixed point types (at least according to the Itanium C++ ABI). One solution is to create a wrapper class, overriding various operators. Another idea is to add name mangling (there is a proposal for the Itanium C++ ABI here [5]). References: [1] - https://lists.llvm.org/pipermail/cfe-dev/2018-April/057756.html [2] - https://lists.llvm.org/pipermail/llvm-dev/2018-August/125433.html [3] - http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf [4] - https://gcc.gnu.org/wiki/FixedPointArithmetic [5] - https://github.com/itanium-cxx-abi/cxx-abi/issues/56

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list