[cfe-dev] [GSoC 2017] Improve loop execution model of the Clang Static Analyzer

[Anna Zaks via cfe-dev]

Hi Péter,

Better modeling of loops is definitely an interesting topic. My main concern would be having a specific proposal on what improvements you could complete in the GSoC timeframe. The next step here is to write down more specifics about what you intend to work on. Please, let me, Devin, and Artem know if you’d like to talk to us while figuring this out.

Cheers!
Anna.


> On Mar 13, 2017, at 9:43 AM, Péter Szécsi <peterszecsi95 at gmail.com> wrote:
> 
> Hello, 
> 
> I would love to work on a Clang Static Analyzer project during the summer by joining GSoC.
> Let me introduce myself:
> I'm Peter Szecsi, a third-year BSc student at Eötvös Loránd University, Budapest. It would be my first Summer of Code project but I have already contributed to clang:
> During the last summer I have uploaded 2 patches:
> - An accepted and merged clang-tidy checker [1] 
> - An accepted Clang SA checker [2]
> Since then I am working on cross translational unit analysis as a university project (and because of that I`ve send some patches about the ASTImporter [3]). Furthermore I participated in the preparations of a talk that was accepted at the EuroLLVM conference. [4]
> I found SA interesting since I like to work on algorithmic challenges and enjoy participating in programming competitions and there is a lot of algorithms in the Static Analyzer which could be optimized/made more precise by heuristics.
> 
> That is the reason why I would be most interested in project "Implement generalized loop execution modeling" from the Clang SA Open Projects page [5]. Hopefully it is a suitable project for GSoC and it is possible to achieve useful improvements during this time frame. 
> I have read the discussion at the "loop widening" patch [6] and the most important enhancements (and milestones in the project) would be invalidating only the possible modified values. In addition to that I was thinking to have some heuristics which would approximate if a loop is too complex to even use this kind of strategy because it would still lead to invalidate most of the values and result in a lot of false positives. Another small heuristic could be: when we already reached the maximum loop unroll number then in case we are sure that there is only a few loopsteps ahead we could unroll it to the end since probably this algorithm will not consume too much time/memory and the result state will not be much more complex. 
> 
> What do you think about these ideas?
> 
> (I have CC'd everyone from the "loop widening" patch discussion.)
> 
> Best regards,
> Peter
> 
> [1] https://reviews.llvm.org/D22507 <https://reviews.llvm.org/D22507>
> [2] https://reviews.llvm.org/D24246 <https://reviews.llvm.org/D24246>
> [3] https://reviews.llvm.org/D29612 <https://reviews.llvm.org/D29612>, https://reviews.llvm.org/D30876 <https://reviews.llvm.org/D30876>, https://reviews.llvm.org/D30877 <https://reviews.llvm.org/D30877>
> [4] http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7 <http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7>
> [5] http://clang-analyzer.llvm.org/open_projects.html <http://clang-analyzer.llvm.org/open_projects.html>
> [6] https://reviews.llvm.org/D12358 <https://reviews.llvm.org/D12358>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170315/140eb0fe/attachment.html>