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

Adrian Prantl via llvm-dev
2017-02-07T17:40:17Z

> 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