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

[Sean Eveson via cfe-dev]

Hello Péter,

Sounds good to me. I'd also be interested in knowing the specifics of what
you are planning to do.

Very happy to help at any point.

Thanks,

Sean Eveson
SN Systems - Sony Interactive Entertainment Group

On Thu, Mar 16, 2017 at 12:49 AM, Anna Zaks <ganna at apple.com> wrote:

> 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
> [2] https://reviews.llvm.org/D24246
> [3] https://reviews.llvm.org/D29612, https://reviews.llvm.org/D30876,
> https://reviews.llvm.org/D30877
> [4] http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7
> [5] http://clang-analyzer.llvm.org/open_projects.html
> [6] https://reviews.llvm.org/D12358
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170316/0277315b/attachment.html>