Fixed point data type support

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fixed point data type support

Xin Wang via cfe-dev

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?

 

 

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

 

        3.    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,

 

cid:image001.jpg@01D25BA7.447BB630

Ye Henry Tian

 

Programming Technologies Lab

Huawei Canada Research Center

19 Allstate Parkway, 3rd floor

Markham, Ontario, Canada L3R 5A4

O. 905-944-5000 ext. 7524

C. 647-289-3222

Email: [hidden email]                   

www.huawei.ca

            Facebook  Instagram  LinkedIn  Twitter

 

This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential to Huawei Technologies Canada Co., Ltd. and/or exempt from disclosure under applicable law.  No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet.  Any unauthorized use, dissemination or copying is strictly prohibited.  If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Fixed point data type support

Xin Wang via cfe-dev

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​

--
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...