[llvm-dev] Fixed Point Support in LLVM (original) (raw)
Leonard Chan via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 20 11:36:11 PDT 2018
- Previous message: [llvm-dev] Liveness Analysis
- Next message: [llvm-dev] Added AllocaInsts are relocated in stack
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [llvm-dev] Liveness Analysis
- Next message: [llvm-dev] Added AllocaInsts are relocated in stack
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]