[LLVMdev] [GSoC] Applying for GSoC 2015

[Mingxing Zhang]

Wow, that is cool!
I'll check about it.

Thank you!

On 4 March 2015 at 21:57, John Criswell <jtcriswel at gmail.com> wrote:

>  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> 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
>>  Web: http://james0zan.github.io/
>>  Addr: Room 3-122, FIT Building, Tsinghua University, Beijing 100084,
>> China
>>
>>
>>  _______________________________________________
>> 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
>>
>>
>
>
> --
>   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 Rochesterhttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150305/f0e21871/attachment.html>