I want to get some latest opinions on “Fixed Point” data type support in LLVM from the community.
From previous mailing list discussions, it seems like Chris [1, 2] and “other people”  prefer of using existing LLVM integer type and builtins to support “Fixed point” data types. I have questions regarding this approach:
- Using exactly the existing LLVM integer type:
a. How to distinguish fixed point data and regular integer data types during lowering and register allocation (if there is operations that operates on different type of registers than GPRs)? (Any functional, performance concerns here?)
b. For parameter passing, linkage support, should we use “attribute” to support it?
c. Will there be any transformations/optimizations (e.g. SROA) that operates on integer types but may not be suitable to Fixed point types?
- Extending the existing LLVM integer type to have sub fields like integer, fraction data parts:
a. It seems like LLVM assumes “We can’t have the same bitwidth for different int types”. This will have a problem with this approach here. How should we solve it?
b. How to handle fixed point constants with this approach? Also how to handle APInt for this approach?
c. How this can affect optimizations, linkage, lowering and register allocation?
- We are also considering introducing new LLVM data types. We think it will cause missing optimization opportunities (e.g. all optimizations that reply on APInt will stop working for the new data type). Is this a valid concern? Are there any other issues that we will run into as well?
Thanks a lot for any comments, suggestions.