[llvm-dev] Fixed Point Support in LLVM

[Leonard Chan via llvm-dev]

We would like to discuss the possibility of adding support for fixed
point operations, either through new types, instructions, or
intrinsics. This is an extension to a previous proposal
(http://lists.llvm.org/pipermail/cfe-dev/2018-April/057756.html) for
implementing fixed point arithmetic entirely in clang, but John McCall
brings up good points in the comments thread of
https://reviews.llvm.org/D50616 for adding LLVM support.

Just to summarize the proposal, Embedded-C lays out an implementation
for fixed point data types and operations on them. A fixed point
number is a number that contains a fractional and integral part. These
types can essentially be represented as scaled integers, that is, a
radix point exists somewhere in the integer that divides it into
integral and fractional bits.

Adding a new type seems unnecessary since all fixed point types in the
spec can be represented as integers. For operations involving these
integers, the scale could ideally be passed as an argument to whatever
instruction or intrinsic is performing a fixed point operation. I’m
not sure of the difference in work between adding a new instruction vs
intrinsic, but this would ideally be done for complex operations.

Namely, intrinsics/instructions would be added for these operations:
- signed multiplication
- signed saturating multiplication
- signed division
- unsigned division
- signed saturating division
- unsigned saturating division
- saturation
- saturating addition
- saturating subtraction
- floating-point to fixed-point conversion

Bevin Hansson has implemented these in his downstream version of
clang/llvm (http://lists.llvm.org/pipermail/cfe-dev/2018-May/058019.html),
and I imagine this is all we may need for intrinsics. We would like to
offset complicated instructions to llvm for targets that provide
native support for these operations while still being able to manage
most of the semantics on the frontend since many simple operations can
be done using existing instructions. These operations will default to
code generated IR for architectures that do not support fixed points
natively.

Does anyone have any more thoughts on how to correctly approach this?

Thanks,
Leo