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

[Rodney M. Bates via llvm-dev]

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