On Mar 22, 2010, at 4:34 PM, Nick Frolov wrote:>> There is a high maintenance cost to having backends in the tree (every >> codegen change requires updating all backends). Adding stuff that >> noone uses and can barely test is not goodness. > > So, proposing a backend for an unpopular architecture is not a good idea > for GSoC project in general?We generally prefer for GSoC projects that are useful to a broad range of people or that opens llvm to a new community. A proposal that implements something that no one will use is highly unlikely to be accepted. -Chris
John Regehr
2010-Mar-23 00:42 UTC
[LLVMdev] Summer of Code idea -- detecting undefined behavior
Is anyone interested in a SoC project to further develop Clang's support for detecting undefined behaviors in C/C++? This is actually a collection of many smaller projects ranging from very easy (detecting divide by zero) to rather nasty (detecting references to out-of-scope automatic variables). If someone does this, I'm happy to help mentor, provide test cases, etc. If done well, this would be a relatively high-impact project. It would catch more errors than valgrind, be faster, and provide much better error messages. John Regehr
Does the C backend serve as a backend of last resort, so to speak? That is, can it be used to generate code for any platform for which there is a C compiler (which presumably would include such 16 bit chips as are still in use for embedded systems and not directly supported by LLVM)?
mån 2010-03-22 klockan 17:23 -0700 skrev Chris Lattner:> We generally prefer for GSoC projects that are useful to a broad range > of people or that opens llvm to a new community.My idea was to propose bringing LLVM to Inferno OS (the complement project of Plan 9 from Bell Labs). This OS has a virtual machine (called Dis) included in the kernel, which is the only option to write user-level applications. Unfortunately only one language can be compiled to its bytecode (Limbo). Inferno does not enjoy significant recognition from general audience, nevertheless it is used in as an embedded OS and a VM running on top of another OS (it is not intended to be a yet-another-language-VM though). Robust compiler infrastructure can attract more developers to Inferno. Lack of support of popular languages is one of major problems on the way of its adoption. It is a better platform to start exploring fundamental ideas of Plan 9 than Plan 9 itself, because there are no hardware compatibility problems by design, as the kernel has out-of-the-box support for running as a user process on a different OS. This work could start with implementing a backend emitting Dis bytecode. For languages that employ pointer arithmetic some kind of sandbox should be added. Later, support of JIT optimizer from LLVM could be added also. Does all this count as opening LLVM to a new community?
On Mar 23, 2010, at 2:47 AM, Nick Frolov wrote:> mån 2010-03-22 klockan 17:23 -0700 skrev Chris Lattner: > >> We generally prefer for GSoC projects that are useful to a broad range >> of people or that opens llvm to a new community. > > My idea was to propose bringing LLVM to Inferno OS (the complement > project of Plan 9 from Bell Labs). This OS has a virtual machine (called > Dis) included in the kernel, which is the only option to write > user-level applications. Unfortunately only one language can be compiled > to its bytecode (Limbo). Inferno does not enjoy significant recognition > from general audience, nevertheless it is used in as an embedded OS and > a VM running on top of another OS (it is not intended to be a > yet-another-language-VM though). > > Robust compiler infrastructure can attract more developers to Inferno. > Lack of support of popular languages is one of major problems on the way > of its adoption. It is a better platform to start exploring fundamental > ideas of Plan 9 than Plan 9 itself, because there are no hardware > compatibility problems by design, as the kernel has out-of-the-box > support for running as a user process on a different OS. > > This work could start with implementing a backend emitting Dis bytecode. > For languages that employ pointer arithmetic some kind of sandbox should > be added. Later, support of JIT optimizer from LLVM could be added also. > > Does all this count as opening LLVM to a new community?Yes, particularly if the Plan 9 folks are interested in incorporating the result into their distribution. -Chris
On Mar 22, 2010, at 6:23 PM, Russell Wallace wrote:> Does the C backend serve as a backend of last resort, so to speak? > That is, can it be used to generate code for any platform for which > there is a C compiler (which presumably would include such 16 bit > chips as are still in use for embedded systems and not directly > supported by LLVM)?Generally yes, but it has some inherent limitations (no exception support, poor debugging support) as well as some current problems (no support for "weird" integer sizes. -Chris
yiqiuping1986
2010-Mar-25 02:21 UTC
[LLVMdev] Summer of Code idea -- detecting undefined behavior
Hi, dear LLVMers I am Qiuping Yi. I am interested in John's SoC project idea, developing Clang's support for detecting undefined behaviors in C/C++, and hope John to be my mentor. I wish to implement detecting some undefined behaivors ranging from easy (such as detecting divide by zero) to rather troublesome ones (such as detecting references to out-of-scope automatic variables). I know well about C/C++, and I major in program analysis and verification. Now I am a grade-two master student of Institute of Software Chinese Academy of Sciences, Beijing, China. I always pay close attention to many compiler optimization technologies. Now I also attend another project based on LLVM, in which I need to implement detecting whether the subscript is out of the bounds of arrays. I hope I can have a chance to make some contribution to LLVM and Clang. Qiuping Yi 2010-03-25 yiqiuping1986 发件人： John Regehr 发送时间： 2010-03-23 08:43:21 收件人： llvmdev 抄送： 主题： [LLVMdev] Summer of Code idea -- detecting undefined behavior Is anyone interested in a SoC project to further develop Clang's support for detecting undefined behaviors in C/C++? This is actually a collection of many smaller projects ranging from very easy (detecting divide by zero) to rather nasty (detecting references to out-of-scope automatic variables). If someone does this, I'm happy to help mentor, provide test cases, etc. If done well, this would be a relatively high-impact project. It would catch more errors than valgrind, be faster, and provide much better error messages. John Regehr _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100325/55191d31/attachment.html>
Hi, dear LLVMers I am Qiuping Yi. I am interested in John's SoC project idea, developing Clang's support for detecting undefined behaviors in C/C++, and hope John to be my mentor. I wish to implement detecting some undefined behaivors ranging from easy (such as detecting divide by zero) to rather troublesome ones (such as detecting references to out-of-scope automatic variables). I know well about C/C++, and I major in program analysis and verification. Now I am a grade-two master student of Institute of Software Chinese Academy of Sciences, Beijing, China. I always pay close attention to many compiler optimization technologies. Now I also attend another project based on LLVM, in which I need to implement detecting whether the subscript is out of the bounds of arrays. I hope I can have a chance to make some contribution to LLVM and Clang. Qiuping Yi 2010-03-25 ------------------------------ yiqiuping1986 ------------------------------ *发件人：* John Regehr *发送时间：* 2010-03-23 08:43:21 *收件人：* llvmdev *抄送：* *主题：* [LLVMdev] Summer of Code idea -- detecting undefined behavior Is anyone interested in a SoC project to further develop Clang's support for detecting undefined behaviors in C/C++? This is actually a collection of many smaller projects ranging from very easy (detecting divide by zero) to rather nasty (detecting references to out-of-scope automatic variables). If someone does this, I'm happy to help mentor, provide test cases, etc. If done well, this would be a relatively high-impact project. It would catch more errors than valgrind, be faster, and provide much better error messages. John Regehr _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100325/e1142cee/attachment.html>