Hi, we are trying to implement in the LLVM framework the fixed point notation as specified in the ISO/IEC TR 18037 ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf ). We've read some old discussions on the mailing list ( f.i. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036674.html , http://lists.llvm.org/pipermail/llvm-dev/2013-December/068473.html ), and it seems that some people don't agree on their implementation as a completely new type. Do you think that today it is worth to implement them or not? Are there anybody working on this? If nobody is already working on this, and the dev community think that it can be a good idea we have a couple of questions: 1- we are following this main guidelines ( http://llvm.org/docs/ExtendingLLVM.html ) in order to add a new type, do you think that it's better a fundamental type or a derived one? 2- Do you have any advice or additional tutorial to suggest in order to implement a new data type? Thank you very much Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151110/b9a7881e/attachment.html>
I have no opinion on whether it is "worth" working on fixed-point. I'm not aware of any discussion or effort in that direction, aside from the email discussions you already found. Non-saturating fixed-point can readily be handled using existing LLVM integer types and tracking the scale factor in the front-end. Languages that support these types (PL/I, COBOL) have done that pretty successfully in other compilers I've worked with. There's no real need for new types to handle these cases. It's the saturating operations that are the problem, and my recollection (reinforced by your links, thanks!) is that inventing new types would be a real problem for people. You are probably best off implementing saturating operations with new LLVM intrinsics, which would (correctly) be avoided by optimization passes, unless you chose to teach a particular pass about the new intrinsics. If this works out, and saturating fixed-point is demonstrably useful and successful, then it would be time to talk about adding new IR types and instructions. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Fabio Gritti via llvm-dev Sent: Tuesday, November 10, 2015 1:54 PM To: llvm-dev at lists.llvm.org Subject: [llvm-dev] FIXED POINT NOTATION Hi, we are trying to implement in the LLVM framework the fixed point notation as specified in the ISO/IEC TR 18037 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf ). We've read some old discussions on the mailing list ( f.i. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036674.html , http://lists.llvm.org/pipermail/llvm-dev/2013-December/068473.html ), and it seems that some people don't agree on their implementation as a completely new type. Do you think that today it is worth to implement them or not? Are there anybody working on this? If nobody is already working on this, and the dev community think that it can be a good idea we have a couple of questions: 1- we are following this main guidelines ( http://llvm.org/docs/ExtendingLLVM.html ) in order to add a new type, do you think that it's better a fundamental type or a derived one? 2- Do you have any advice or additional tutorial to suggest in order to implement a new data type? Thank you very much Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/7653ec1c/attachment.html>
> On Nov 10, 2015, at 1:54 PM, Fabio Gritti via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, we are trying to implement in the LLVM framework the fixed point notation as specified in the ISO/IEC TR 18037 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf> ). > > We've read some old discussions on the mailing list ( f.i. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036674.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036674.html> , http://lists.llvm.org/pipermail/llvm-dev/2013-December/068473.html <http://lists.llvm.org/pipermail/llvm-dev/2013-December/068473.html> ), and it seems that some people don't agree on their implementation as a completely new type. > Do you think that today it is worth to implement them or not? Are there anybody working on this? > > If nobody is already working on this, and the dev community think that it can be a good idea we have a couple of questions: > > 1- we are following this main guidelines ( http://llvm.org/docs/ExtendingLLVM.html <http://llvm.org/docs/ExtendingLLVM.html> ) in order to add a new type, do you think that it's better a fundamental type or a derived one? > > 2- Do you have any advice or additional tutorial to suggest in order to implement a new data type?Hi Fabio, I’d suggest bringing this up on the cfe-dev mailing list, since this is likely to be a pure clang extension and have little impact on LLVM itself (at least in the short term, it is possible that LLVM extensions will eventually be interesting to improve the implementation). -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151110/63a63e27/attachment.html>