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

Rodney M. Bates via llvm-dev
2017-02-06T03:13:08Z

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