Ye Tian (Henry, Canada Research Center) via llvm-dev
2017-Jul-05 15:20 UTC
[llvm-dev] Fixed point data type support
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 at 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: ye.tian1 at huawei.com <mailto:ye.tian1 at huawei.com > www.huawei.ca<http://www.huawei.ca/> [Facebook] <https://www.facebook.com/HuaweimobileCAN/> [Instagram] <https://www.instagram.com/huaweicanada/> [LinkedIn] <https://www.linkedin.com/company-beta/3014?pathWildcard=3014> [Twitter] <https://twitter.com/huawei_canada?lang=en> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/06827c05/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4841 bytes Desc: image001.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/06827c05/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 724 bytes Desc: image002.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/06827c05/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 768 bytes Desc: image003.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/06827c05/attachment-0002.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 744 bytes Desc: image004.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/06827c05/attachment-0003.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 749 bytes Desc: image005.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/06827c05/attachment-0004.jpg>
> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/3f09fb1f/attachment.html>