[llvm-dev] Fixed Point Support in LLVM

[Philip Reames via llvm-dev]

A couple of thoughts here.  None particularly well thought out, so 
please take this more as brainstorming then specific recommendations.

In terms of typing, have you considered representing your fixed points 
as structs in IR as apposed to packed integers?  I suspect - but am by 
no means sure - that exposing the parts to the optimizer separately may 
lead to better overall optimization quality.  SROA is quite good at 
destroying small structs.

In terms of ABI, how are fixed points passed as arguments and return 
values?  This may impact your choice of IR representation. If you can 
get away with something simple (e.g. passed as iN, bitcast to desired 
types) you'll be much better off then if you have a complicated ABI.

If I understand your operations, you're going to need to have the scale 
as an explicit parameter to your intrinsics right?  If so, you're 
essentially going to end up with needing a family of intrinsics for each 
operation.  You have a couple of approaches for modeling that: either 
constant parameters or name manging might work.

Have you considered phrasing this as builtin functions as opposed to 
intrinsics?  We have fairly decent support in TLI for conditionally 
available builtins where as intrinsics are generally assumed to be 
always supported.  Phrasing your operations as a set of builtins 
implemented by a runtime library may allow both easier prototyping and 
easier per target integration.  In particular, pattern matching IR to 
the operations would be much more natural if framed as TLI functions 
since we have the concept of an unsupported builtin already supported.

Philip



On 08/20/2018 10:59 AM, Leonard Chan via llvm-dev wrote:
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev