[LLVMdev] [GSoC] Applying for GSoC 2015

[John Criswell]

On 3/4/15 2:18 AM, Mingxing Zhang wrote:
> Hello John,
>
> Thank you for your advices and congratulations~
>
> I'll read the code of cfl-aa and Giri first and make the decision of 
> which project to pursue.
> The choice will be reported to this thread once I made the 
> determination (hopefully within this week).

You should check for yourself, but I don't think anything prevents you 
from submitting two proposals.  If you have time to write two strong 
proposals, I see no problem with that.

Just make sure that any proposal you write is strong: it provides a 
concrete explanation of what you want to do, some justification for why 
it would benefit the community (short or long term), and why you're the 
person qualified to do it.  Proposals should also include a set of 
milestones and expected dates for completing those milestones.

Regards,

John Criswell

>
> Thanks!
>
>
> On 3 March 2015 at 23:12, John Criswell <jtcriswel at gmail.com 
> <mailto:jtcriswel at gmail.com>> wrote:
>
>     Dear Mingxing,
>
>     I think both projects are interesting and useful.
>
>     Points-to analysis is something that is needed by research users
>     of LLVM, but to the best of my knowledge, no solid implementation
>     currently exists (although the cfl-aa work being done at Google
>     may provide us with something; you should check into it before
>     writing a proposal).  My interest is in a points-to analysis that
>     is robust and is useful to both research and industry users of
>     LLVM.  A points-to analysis proposal must indicate how it will
>     help both of these subsets of the LLVM community, and it must
>     argue why current efforts do not meet the requirements of both
>     subsets of the community.
>
>     The runtime bloat tool also looks interesting, and your approach
>     (at least to me) is interesting.  One question in my mind, though,
>     is whether dynamic slicing is going to work well.  Swarup Sahoo
>     and I built a dynamic slicer for LLVM named Giri, and we found the
>     tracing required for dynamic slicing to be slow.  For our
>     purposes, the overhead was okay as we only needed to record
>     execution until a crash (which happened quickly).  In your bloat
>     tool, the program will probably run for awhile, creating a long
>     trace record.  You should take a look at the Giri code, use it to
>     trace some programs, and see if the overheads are going to be
>     tolerable.  If they are not, then your first task would be to
>     optimize Giri for your bloat tool.
>
>     You should also be more specific about which LLVM instructions
>     will be traced.  For example, I wouldn't record the outputs of
>     every LLVM instruction; I might only record the outputs of loads
>     and stores or the end of a def-use chain.
>
>     I'd be interested in mentoring either project.
>
>     BTW, it looks like your FSE paper won an award. Congrats.
>
>     Regards,
>
>     John Criswell
>
>
>
>
>
>
>
>     On 3/3/15 2:30 AM, Mingxing Zhang wrote:
>>     Hi all,
>>
>>     As a Ph.D. student majored in Software Reliability, I have used
>>     LLVM in many of my projects, such as the Anticipating Invariant
>>     (http://james0zan.github.io/AI.html) and some other undergoing ones.
>>     Thus, it would be a great pleasure for me if I could take this
>>     opportunity to contribute to this awesome project.
>>
>>     After reading the idea list (http://llvm.org/OpenProjects.html),
>>     I was most interested in the idea of improving the "Pointer and
>>     Alias Analysis" passes.
>>     Could you please give me some more tips or advices on how to get
>>     started on working on the application?
>>
>>     Simultaneously, I also have another idea about using LLVM to
>>     detect runtime bloat, just like the ThreadSanitizer tool for data
>>     races.
>>     If there is anyone here who would like to mentor this project,
>>     could you please find some time to review the more detailed
>>     proposal on gist
>>     <https://gist.github.com/james0zan/d03737c60b10d0d11d34> and give
>>     me some feedbacks?
>>
>>     P.S.
>>       I do prefer the bloat detection tool, but I'm not sure about
>>     whether it is suitable for GSoC.
>>       Thus I will apply for the Alias Analysis one if it is not suitable.
>>
>>     Thanks!
>>
>>     -- 
>>     Mingxing Zhang
>>
>>     Tel.: +86-10-62797143 <tel:%2B86-10-62797143>
>>     Web: http://james0zan.github.io/
>>     Addr: Room 3-122, FIT Building, Tsinghua University, Beijing
>>     100084, China
>>
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu  <mailto:LLVMdev at cs.uiuc.edu>          http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     /
>
>     -- 
>     John Criswell
>     Assistant Professor
>     Department of Computer Science, University of Rochester
>     http://www.cs.rochester.edu/u/criswell
>
>
>
>
> -- 
> Mingxing Zhang
>
> Tel.: +86-10-62797143
> Web: http://james0zan.github.io/
> Addr: Room 3-122, FIT Building, Tsinghua University, Beijing 100084, China


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150304/61ed3acd/attachment.html>