[LLVMdev] [GSoC] Applying for GSoC 2015
Mingxing Zhang
james0zan at gmail.com
Wed Mar 4 17:58:59 PST 2015
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>
More information about the llvm-dev
mailing list