[LLVMdev] [GSoC] Applying for GSoC 2015
james0zan at gmail.com
Tue Mar 3 23:18:04 PST 2015
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).
On 3 March 2015 at 23:12, John Criswell <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.
> 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"
> 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
> 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.
> Mingxing Zhang
> Tel.: +86-10-62797143
> Web: http://james0zan.github.io/
> Addr: Room 3-122, FIT Building, Tsinghua University, Beijing 100084,
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell
Addr: Room 3-122, FIT Building, Tsinghua University, Beijing 100084, China
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev