[llvm-dev] Fixed Point Support in LLVM

[Bevin Hansson via llvm-dev]

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