llvm dev - Feb 2017 - Your help needed: List of LLVM Open Projects 2017 (Modula-3)

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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing

Do we have any open projects on LLD?

I know we usually try to avoid any big "projects" and mainly add/fix
things
in response to user needs, but just wondering if somebody has any ideas.

Some really generic/simple stuff I can think of:
1. trying out LLD on a large program corpus and reporting/reducing/fixing
bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
packages from a linux distro like Debian or Gentoo)
2. performance analysis and optimization of LLD
3. getting LLD to link a bootable Linux kernel and/or GRUB
4. write an input verifier such that LLD can survive intensive fuzzing with
no crashes / fatal errors [1] when the verifier says the input is okay.
This will allow us to measure what the overhead of doing this actually is.


[1] As of the latest LLD discussion (in the thread "[llvm-dev] LLD status
update and performance chart") it sounds like people are okay with LLD
treating fatal errors the same way that LLVM uses assertions; for inputs
from the C++ API, we can document to not pass corrupted object files. For
inputs read from files, there is still community interest in at least
having the option to run a "verifier" to validate the inputs. I think
the
best way to approach the verifier is to essentially follow the approach
suggested by Peter (in the context of "hardening") in
https://llvm.org/bugs/show_bug.cgi?id=30540#c5 i.e. getting to the point
where LLD can survive intensive fuzzing.

-- Sean Silva

On Mon, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/fef48ff1/attachment.html>

The list can't ommit clang-tidy.
There are many ideas about new checks on llvm bugzilla.
https://llvm.org/bugs/buglist.cgi?product=clang-tools-extra&component=clang-tidy&resolution=---&list_id=110936
Everything matching ".*Feature Request.*"

Piotr

2017-01-16 21:31 GMT+01:00 Sean Silva via cfe-dev <cfe-dev at
lists.llvm.org>:
> Do we have any open projects on LLD?
>
> I know we usually try to avoid any big "projects" and mainly
add/fix
> things in response to user needs, but just wondering if somebody has any
> ideas.
>
> Some really generic/simple stuff I can think of:
> 1. trying out LLD on a large program corpus and reporting/reducing/fixing
> bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
> packages from a linux distro like Debian or Gentoo)
> 2. performance analysis and optimization of LLD
> 3. getting LLD to link a bootable Linux kernel and/or GRUB
> 4. write an input verifier such that LLD can survive intensive fuzzing
> with no crashes / fatal errors [1] when the verifier says the input is
> okay. This will allow us to measure what the overhead of doing this
> actually is.
>
>
> [1] As of the latest LLD discussion (in the thread "[llvm-dev] LLD
status
> update and performance chart") it sounds like people are okay with LLD
> treating fatal errors the same way that LLVM uses assertions; for inputs
> from the C++ API, we can document to not pass corrupted object files. For
> inputs read from files, there is still community interest in at least
> having the option to run a "verifier" to validate the inputs. I
think the
> best way to approach the verifier is to essentially follow the approach
> suggested by Peter (in the context of "hardening") in
> https://llvm.org/bugs/show_bug.cgi?id=30540#c5 i.e. getting to the point
> where LLD can survive intensive fuzzing.
>
> -- Sean Silva
>
> On Mon, 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
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/f967b177/attachment.html>

On 16 January 2017 at 15:31, Sean Silva <chisophugis at gmail.com>
wrote:
> Do we have any open projects on LLD?
>
> I know we usually try to avoid any big "projects" and mainly
add/fix things
> in response to user needs, but just wondering if somebody has any ideas.
>
> Some really generic/simple stuff I can think of:
> 1. trying out LLD on a large program corpus and reporting/reducing/fixing
> bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
> packages from a linux distro like Debian or Gentoo)
>From Rafael's last Poudriere ports build I think about 98% of the
packages are building with LLD, and some of the missing ones are those
that were skipped (e.g. do not build on amd64, or the upstream
distfiles have gone away). I think some next steps here for FreeBSD
include:

* Ensure we're running the test suites in packages that have them
* Actually install and use the resulting packages for a smoke test
* Address the WIP patches / workarounds currently in use
* Triage the few hundred failures
>From the FreeBSD perspective there's one key LLD task of interest:
* Bring other architecture support to parity with amd64/x86_64. For us
the next one in importance is AArch64/arm64, then i386 and 32-bit arm,
and 32- and 64-bit MIPS, PowerPC, and RISC-V.

On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Do we have any open projects on LLD?
>
> I know we usually try to avoid any big "projects" and mainly
add/fix things
> in response to user needs, but just wondering if somebody has any ideas.
>
I'm not particularly active in lld anymore, but the last big item I'd
like to see implemented is Pettis-Hansen layout.
http://perso.ensta-paristech.fr/~bmonsuez/Cours/B6-4/Articles/papers15.pdf
(mainly because it improves performances of the final executable).
GCC/gold have an implementation of the algorithm that can be used as
base. I'll expand if anybody is interested.
Side note: I'd like to propose a couple of llvm projects as well, I'll
sit down later today and write them.

--
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva <chisophugis at gmail.com>
wrote:
> Do we have any open projects on LLD?
>
> I know we usually try to avoid any big "projects" and mainly
add/fix
> things in response to user needs, but just wondering if somebody has any
> ideas.
>
> Some really generic/simple stuff I can think of:
> 1. trying out LLD on a large program corpus and reporting/reducing/fixing
> bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
> packages from a linux distro like Debian or Gentoo)
>
I like that idea. FreeBSD is using a very old version of ld.bfd, so on
Linux systems we may be able to find programs that use recent linker
features which LLD does not support. This may sound like an ambitious goal,
but I want make Linux distributions to use LLD as default linker, so it
needs to be able to link entire Linux distributions.

2. performance analysis and optimization of LLD
> 3. getting LLD to link a bootable Linux kernel and/or GRUB
>
I don't know how hard/easy it is to link Linux kernel with LLD, but that
should be doable if we spend enough effort on that. That should be a good
project.

As to porting LLD to other architectures, you can use emulators like bochs,
can't you? You don't even need any emulator for x86 32-bit.

4. write an input verifier such that LLD can survive intensive fuzzing
with
> no crashes / fatal errors [1] when the verifier says the input is okay.
> This will allow us to measure what the overhead of doing this actually is.
>
>
> [1] As of the latest LLD discussion (in the thread "[llvm-dev] LLD
status
> update and performance chart") it sounds like people are okay with LLD
> treating fatal errors the same way that LLVM uses assertions; for inputs
> from the C++ API, we can document to not pass corrupted object files. For
> inputs read from files, there is still community interest in at least
> having the option to run a "verifier" to validate the inputs. I
think the
> best way to approach the verifier is to essentially follow the approach
> suggested by Peter (in the context of "hardening") in
> https://llvm.org/bugs/show_bug.cgi?id=30540#c5 i.e. getting to the point
> where LLD can survive intensive fuzzing.
>
> -- Sean Silva
>
> On Mon, 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/1c8cc08c/attachment.html>

A gentle ping ;)
On 16/01/17 14:18, Vassil Vassilev 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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>

A couple of Modula-3 developers have worked on splicing LLVM on as an
alternative
back end to the Modula-3 compiler, out-of-tree (the LLVM tree), of course.  A
major
portion of the necessary glue code is there, and at one time, I was able to get
the
M3 compiler and the libraries it needs to rebuild themselves twice, using the
LLVM
back end, although that seems to have regressed.

This work has been stalled since sometime last spring, with the discovery that
the
debug info passed through LLVM is in fact, equivalent to only a small subset of
Dwarf.  The decisive discovery was that the debug info for a subrange type does
not
allow a base type to be noted, even though Dwarf does.  Modula-3 allows
subranges
of any of a few builtin types and an extremely large potential set of
programmer-defined
enumeration types, so this is pretty much unusable for subranges.

Speaking for myself, one of the primary motives for wanting an LLVM back end
is better debug information.  The current debug info is a horribly cobbled-up
extension of stabs, with the majority of the useful information encoded inside
the string fields of stabs, in ways the various stabs definitions know nothing
about, leaving stabs largely just a container.

There has been a discussion on this list about separating LLVM debug info for
types
and bypassing this around most of the optimization and code generation.  This
would
help a lot, but it has not been clear to me how this has played out.

This work is still at LLVM 3.6.1.  Even without the type bypassing, I know
DIBuilder
has changed a lot.  Twice, I have gone through the process of creating bindings
to
DIBuilder and a few other needed things.  It is extremely tedious and
error-prone,
because there is no cross-language type checking whatsoever,  so I hope to do it
again as seldom as possible, hopefully at most once more.

Modula-3 has object-oriented types with dispatching methods and single
inheritance,
but the bindings we have created so far have C bindings in between, and I
haven't
come up with a nice way to handle the dynamic types of the pointers. 
Eventually,
it would be nice to have some kind of ABI compatibility and avoid C altogether,
but I doubt this is feasible without doing it the current way first, as an
intermediate step.

On 01/16/2017 07:18 AM, Vassil Vassilev via llvm-dev
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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Rodney Bates
rodney.m.bates at acm.org

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
<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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
> _______________________________________________
> 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/2c49f0a5/attachment.html>

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 <mailto: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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto: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/ec26f62a/attachment.html>

> On Feb 5, 2017, at 7:13 PM, Rodney M. Bates via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> A couple of Modula-3 developers have worked on splicing LLVM on as an
alternative
> back end to the Modula-3 compiler, out-of-tree (the LLVM tree), of course. 
A major
> portion of the necessary glue code is there, and at one time, I was able to
get the
> M3 compiler and the libraries it needs to rebuild themselves twice, using
the LLVM
> back end, although that seems to have regressed.
> 
> This work has been stalled since sometime last spring, with the discovery
that the
> debug info passed through LLVM is in fact, equivalent to only a small
subset of
> Dwarf.  The decisive discovery was that the debug info for a subrange type
does not
> allow a base type to be noted, even though Dwarf does.  Modula-3 allows
subranges
> of any of a few builtin types and an extremely large potential set of
programmer-defined
> enumeration types, so this is pretty much unusable for subranges.
We are certainly interested in supporting more DWARF features in LLVM's
DWARF backend and metadata. While the amount of code necessary to support a new
attribute/tag/... may seem intimidating at first, the actual work is rather
mechanical and not very hard. I'd be happy to walk you through the steps if
you are interested in contributing new features. Having more complete DWARF (and
CodeView) support will benefit many out-of-tree language frontends.
> 
> Speaking for myself, one of the primary motives for wanting an LLVM back
end
> is better debug information.  The current debug info is a horribly
cobbled-up
> extension of stabs, with the majority of the useful information encoded
inside
> the string fields of stabs, in ways the various stabs definitions know
nothing
> about, leaving stabs largely just a container.
> 
> There has been a discussion on this list about separating LLVM debug info
for types
> and bypassing this around most of the optimization and code generation. 
This would
> help a lot, but it has not been clear to me how this has played out.
There are a still a lot of unsolved technical challenges down this road (cf. the
roadmap that Eric Christopher sent out last year) and even after this is
finished, the amount of work to support new features (adding support for a new
feature to the various debug info backends, etc) would still be about the same,
so wouldn't necessarily recommend waiting this out.
> This work is still at LLVM 3.6.1.  Even without the type bypassing, I know
DIBuilder
> has changed a lot.  Twice, I have gone through the process of creating
bindings to
> DIBuilder and a few other needed things.  It is extremely tedious and
error-prone,
> because there is no cross-language type checking whatsoever,  so I hope to
do it
> again as seldom as possible, hopefully at most once more.
Can you give an example of what you mean by cross-language type checking?
I'd be interested in learning how we can improve the API.

-- adrian
> Modula-3 has object-oriented types with dispatching methods and single
inheritance,
> but the bindings we have created so far have C bindings in between, and I
haven't
> come up with a nice way to handle the dynamic types of the pointers. 
Eventually,
> it would be nice to have some kind of ABI compatibility and avoid C
altogether,
> but I doubt this is feasible without doing it the current way first, as an
> intermediate step.
> 
> On 01/16/2017 07:18 AM, Vassil Vassilev via llvm-dev 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_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev