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). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150304/dbe25daa/attachment.html>
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>
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>