[cfe-dev] GSoC 2018

Mikhail Ramalho via cfe-dev cfe-dev at lists.llvm.org
Wed Mar 21 10:12:15 PDT 2018


Hi all,

I've written a first draft of my proposal:

https://docs.google.com/document/d/1-zNSv0l4WyoxYpJUAw8LFnQq_TY4AGjIpPu1VPkmO-g/edit?usp=sharing

I've added a few comments in places I think need improvement.

May I ask the community to have a look and give some feedback?

Thank you,


2018-03-12 18:24 GMT+00:00 George Karpenkov <ekarpenkov at apple.com>:

> Hi Mikhail,
>
> I’m assuming Dominic have answered your questions regarding the point (3).
>
> On point (1) I have recently sent an email on the list answering, I
> believe, to essentially the same question:
> http://lists.llvm.org/pipermail/cfe-dev/2018-March/057064.html
>
> (yes, unfortunately we do not have better archives, so messages might be
> often hard to track)
>
> 2. I still don't quite understand how dynamic memory track works in the
> analyzer, is the double checker expected to work for pointers and dynamic
> memory as well? I'm assuming yes here and that Z3ConstraintManager might
> need to be extended somehow (a plan will be added to the proposal).
>
>
> I think here we should get the extra precision for free by adding a bug
> reporter visitor, as described in the email thread I have linked to.
>
> Please feel free to ask any further questions, bug reporter visitors are
> quite messy in the analyzer.
>
> Regards,
> George
>
>
> ~
>
> 3. This is a list of the TODOs in Z3ConstraintManager, from more
> important to less important, in my opinion. I just want to know if the
> analyzer's developers (and the project mentor) agree with this list, as it
> might go into my proposal:
>
> 3.1. Don't assume nearest ties to even rounding mode: currently, only
> rounding to even is supported, even if the code changes the rounding mode
> using fesetround.
>
> 3.2. Don't add all the constraints, only the relevant ones: adding
> unnecessary constraints will slowdown the solver.
>
> 3.3. Refactor doTypeConversion to use built-in conversion functions (Refactor
> to Sema::FindCompositePointerType(), and Sema::CheckCompareOperands(); Refine
> behavior for invalid type casts)
> 3.4. Refactor doIntTypeConversion to use Sema::handleIntegerConversion()
> 3.5. Refactor doFloatTypeConversion to use Sema::handleFloatConversion()
>
> I bundled this together because, although the conversion seems incomplete
> (based on the comments), it's about removing duplicated code.
>
> 3.6. Refactor getAPSIntType(const llvm::APSInt &Int) const to put
> elsewhere.
>
> ~
>
> Thank you,
>
>
> 2018-02-24 1:03 GMT+00:00 Devin Coughlin <dcoughlin at apple.com>:
>
>>
>>
>> > On Feb 23, 2018, at 9:29 AM, Mikhail Ramalho via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>> >
>> > I also have a question about the proposal. I understand that ideas
>> about the project will be discussed in the mailing list. However, once
>> that's settled and I write my first draft proposal, should I send it to the
>> mailing list for discussion again or should I send it only to the mentor?
>>
>> Please make sure to keep email discussions on the mailing list rather
>> than just personal email. This is a topic that members of the community
>> will be interested in and will have valuable feedback on.
>>
>> Devin
>>
>>
>
>
> --
>
> Mikhail Ramalho.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>


-- 

Mikhail Ramalho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180321/a9bdc7c3/attachment.html>


More information about the cfe-dev mailing list