llvm dev - Mar 2010 - [LLVMdev] Summer of Code ideas

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

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

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>