[llvm-dev] Your help needed: List of LLVM Open Projects 2017

Tue Feb 7 08:39:47 PST 2017

2017-02-07 2:12 GMT+01:00 Anna Zaks <zaks.anna at gmail.com>:

>
>
> On Mon, Feb 6, 2017 at 12:55 PM, Piotr Padlewski <
> piotr.padlewski at gmail.com> wrote:
>
>> Hi,
>> sorry for long response, finals time.
>>
>> I searched for some fun checks in bugzilla, and I only have found one
>> that would require some more work than 1 week.
>> There are also many small features that doesn't have bugs on bugzilla,
>> but can be found in the code. I can direct for these if someone would like
>> to have some more info.
>>
>> I also added one line for LLVM: I heard many people would like to have
>> buffered LLVM IR output for -emit-after-all (so that it shows dump for
>> function only if it differs).
>>
>> @Anna I saw that "Warn if virtual calls are made from constructors or
>> destructors" is proposed as new SA checker. Wouldn't it make more sense to
>> have it in clang-tidy?
>> I guess it depends on the exact scope of the checker. Fiding virtual
>> calls directly in ctor is trivial to do using AST Matchers.
>>
>
> You'd have to double check but my understanding is that the checker that
> provides the functionality you describe (using matching of the ASTs) has
> been part of the analyzer for a while (since 2012). It's called
> VirtualCallChecker.cpp. As I mentioned before, I do not think we should
> move all existing analyzer AST-matching checks into clang-tidy since not
> all users of the analyzer use clang-tidy and there is no technical reason
> to do that either. The open project is to re-implement a part of the
> checker as a path-sensitive and inter-procedural checker, which would be
> more precise and not prone to false positives. The specific examples of
> false positives that we want to be addressed by having the checker to be
> re-implemented as path-sensitive is explained in the project description.
>
>
> I am not sure if there is benefit in implementing a clang-tidy checker for
> a similar property, maybe there is but it would not be related or a
> replacement for this project. It would likely have higher false positives,
> but could qualify for a stylistic rule that some developers would want to
> follow, making it a good fit for clang-tidy.
>
> Thanks, I guess it was too late for me to process that fully, that make
sense.

Piotr


> Fiding virtual call called from other function would be a little bit
>> harder, but still doable easily. I belive clang-tidy is also better place
>> for it, because code calling virtual function inside ctor might be still
>> valid code (and depending if it is called directly or not, we can provide
>> fixit like "this->Base::foo()"). I would argue if we want to warn in cases
>> like:
>>
>> void foo(A &a) { a.bar(); }
>>
>> A::A() {
>>   foo(*this);
>> }
>>
>> As long as a::bar is not pure, this might be valid code, that uses foo in
>> multiple places in code.
>> But I agree that fiding calls to pure functions might inside other
>> functions might be better to do in SA.
>>
>>
>> Piotr
>>
>>
>> 2017-02-06 20:07 GMT+01:00 Vassil Vassilev via llvm-dev <
>> llvm-dev at lists.llvm.org>:
>>
>>> Hi Matthias,
>>>
>>>   Thanks a lot for the project. Could you put it in the google doc
>>> below? I'd appreciate if you could follow more-or-less the format. Are you
>>> going to be the mentor.
>>>
>>> Cheers, Vassil
>>>
>>> On 06/02/17 19:29, Matthias Braun wrote:
>>>
>>> Here's another one:
>>>
>>> = Improve code generation testing =
>>>
>>> After instruction selection LLVM uses the MI (Machine Instruction)
>>> representation for programs. We recently added support for reading and
>>> writing this representation to disk (http://llvm.org/docs/MIRLangR
>>> ef.html). Usage of this format for writing tests is growing and so is
>>> the desire to improve the format, tools and workflow. Improvements would be
>>> welcome:
>>>
>>> - Create a single consistent format instead of the current mix of yaml +
>>> IR + MIR
>>> - Do not print unnecessary information (we often print default values
>>> where the reader could deduce them)
>>> - Allow the representation to deduce successors of a basic block in
>>> common cases
>>> - Allow symbolic names instead of just numbers for virtual registers
>>> - Helper passes: Strip IR information, rename blocks and values, debug
>>> information, ...
>>> - Create a bugpoint mode (or a new tool) to reduce .mir test cases
>>> - Write recommendations and guides for .mir based tests
>>>
>>> - Matthias
>>>
>>> On Jan 16, 2017, at 5:18 AM, Vassil Vassilev via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> Hi folks,
>>>
>>>  Happy new year!
>>>
>>>  Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation
>>> LLVM Developers'. It was suggested that we should update our open projects
>>> page and possibly restructure it a little bit.
>>>
>>>  I volunteered to do this work and I need your help.
>>>
>>>
>>>  Chandler and I started working on a google doc [1]. We pinged few code
>>> owners asking them to list of work items we should get done in 2017 but we
>>> do not have the manpower. Now we would like to ask for your input, too.
>>>
>>>  I believe an up to date list can serve as a good entry point for
>>> students, interns and new contributors.
>>>
>>>  Feel free to propose a new item or comment under an existing one. I
>>> expect to start gradually updating the page beginning of Feb.
>>>
>>> -- Vassil
>>>
>>> [1] https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n
>>> 0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170207/8350a7ed/attachment.html>