[LLVMdev] [GSoC] Applying for GSoC 2015

John Criswell jtcriswel at gmail.com
Tue Mar 3 07:12:53 PST 2015


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
> 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         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

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


More information about the llvm-dev mailing list