Fixed point data type support

Project Infrastructure LLVM Dev List Archives
1

Hi,

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” [2] prefer of using existing LLVM integer type and builtins to support “Fixed point” data types. I have questions regarding this approach:

  1. 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?

  1. 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?

  1. 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?

[1] http://lists.llvm.org/pipermail/llvm-dev/2010-November/036645.html

[2] https://groups.google.com/forum/#!topic/llvm-dev/-bm8HzBQN94

Thanks a lot for any comments, suggestions.

Best,

image001.jpg

image002.jpg

image003.jpg

image004.jpg

image005.jpg

2

1. 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?

​From what I can tell from the links you provide, the general suggestion is​

​let Clang emit fix-point type as LLVM integer type (iN). Perhaps you can
distinguish it (say, i40) from regular integer type (i32), and make backend
use particular register or operation on it. If not, you have to emit LLVM
(?) intrinsic to help LLVM make the decision.

​Regards,
chenwj​