[llvm-dev] Fixed Point Support in LLVM

[Leonard Chan via llvm-dev]

Hi all,

We will be adding intrinsics for now to get a working version of fixed
point arithmetic implemented in clang faster, but will still consider
either adding a new fixed point type in LLVM or new operations that
perform these fixed point operations on integers. This is a list of
all the intrinsics that I plan to implement and wanted to see if
anyone had any feedback on their signatures/semantics.

; Signed and unsigned saturation
; Unsigned saturation would primarily just saturate to W_MAX since you
can’t really saturate towards 0 for an unsigned number
declare iN @llvm.ssaturate(iN %Val, i32 %W)
declare iN @llvm.usaturate(iN %Val, i32 %W)

; Saturated addition and subtraction.
; Scale is not necessary since fixed addition/subtraction does not
care about the scale as long as the operands have the same scale. This
will require a shift beforehand regardless.
; We cannot use the existing overflow add/sub intrinsics since they
only indicate overflow but not direction to saturate in.
declare iN @llvm.satsadd(iN %L, iN %R)
declare iN @llvm.satuadd(iN %L, iN %R)
declare iN @llvm.satssub(iN %L, iN %R)
declare iN @llvm.satusub(iN %L, iN %R)

; Multiplication and division
declare iN @llvm.fixsmul(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixumul(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixsdiv(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixudiv(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixsmul.sat(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixumul.sat(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixsdiv.sat(iN %L, %iN R, i32 %Scale)
declare iN @llvm.fixudiv.sat(iN %L, %iN R, i32 %Scale)

- Leo
On Tue, Aug 28, 2018 at 12:47 AM Bevin Hansson
<bevin.hansson at ericsson.com> wrote:
>
> Hi,
>
>
> On 2018-08-28 07:36, Chris Lattner via llvm-dev wrote:
> > Hi Leonard,
> >
> > I’m sorry for the delay responding to this.  Please let me +1 a few downstream comments:
> >
> > +1 for adding a first class type.  I agree with John that this is not as bad as it might seem.  This allows the core LLVM IR types (e.g. add sub etc) to be defined on these types, and for legalize to do the right thing.  This makes it easier for producers of IR (e.g. clang) to handle them in a uniform way.  I don’t see a downside to this.
> Assuming you meant 'operators' rather than 'types', there's an issue
> with that. Every line of code in LLVM today assumes that the add, sub et
> al. operate on integer types. Fixing that assumption sounds like quite a
> bit of work to me, so I think we would likely have to add new operators
> for all of the fixed point types. Some of those operators (like
> non-saturating add and sub) would essentially do the exact same thing as
> regular add and sub anyway, so we'd get needless duplication.
>
> Regarding legalization: depending on where we do legalization of
> fixed-point types/operations, it could get hairy. The type system during
> lowering is pretty simplistic. Fixed-point types would add multiple
> dimensions to the system (width, scale, possibly padding if we include
> that), which I think might be hard to represent efficiently in the
> MVT/EVT system.
> > +1 to Philip’s point about getting much of an implementation in place before starting integration.  This is a big enough piece of work that we should be confident in the design direction, and I don’t want to get another partial transition into the codebase that may or may not get finished.
> So does this mean it would be implemented using integers and intrinsics
> first, and then moved to a new type solution?
>
> If the first solution ends up working well, would it be an unreasonable
> option to use it instead?
>
> / Bevin