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

Piotr Padlewski via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 6 12:55:46 PST 2017


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. 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/MIRLangRef.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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfy
> piX0YDQBc/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/20170206/e7ef3632/attachment.html>


More information about the llvm-dev mailing list