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

Tue Feb 7 16:56:38 PST 2017

> On Feb 7, 2017, at 1:38 PM, Rodney M. Bates <rodney_bates at lcwb.coop> wrote:
> 
> 
> 
> On 02/07/2017 11:40 AM, Adrian Prantl wrote:
>> 
>>> 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.
>> 
> 
> I would be very interested in such a walk through.  I could see that it would be
> conceptually straightforward, but just finding all the relevant places is very daunting.
> I find that locating just about anything in a large body of C++ code to be a needle-
> in-haystack operation.  Perhaps there is something I don't know.  Just knowing where
> all the places are to add a Dwarf node or field would be a big help.

Just today there was a collection of patches posted that add new DWARF expressions to clang, LLVM IR metadata, and the DWARF backend (http://lists.llvm.org/pipermail/llvm-dev/2017-February/109919.html). These are a nice starting point highlighting all the moving parts that need to be touched when adding new DWARF features. Another good example on extending the debug info metadata is the recent support for alignment attributes and the discussions relating to it.
I would suggest checking these out and then I'm happy to answer more specific questions as they come up.

> 
>>> 
>>> 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.
>> 
> 
> OK, I'll leave that idea alone for now.
> 
>>> 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.
>> 
> 
> If I call a procedure written in M3 from M3 code, I can't avoid having the compiler
> check that my parameter numbers, types, modes match.  In C or C++, I can get equivalent
> checking to happen if I follow a suitable header file idiom.  But there is, AFAIK, no
> tool to check parameters between a procedure/function signature coded in one language
> and one in another language.  And DIBuilder in particular has perhaps a hundred functions,
> most of which have in the teens of parameters each.
> 
> 
> A binding generator would be nice, probably built on top of clang, but that's a lot of work.
> 
> I don't think of a way API changes might help, other than eliminating overloaded functions
> and somehow flattening pointers to members of class hierarchies.  But that is, I think,
> more or less what the existing C bindings do, and they lose a lot of type information.
> The bindings I have done include a C binding in similar style, plus a zero-thickness
> Modula-3 binding with nothing but signatures.

I also found the C bindings to DIBuilder to be particularly lacking both type safety and features. Is your compiler frontend written in Modula? I think rolling your own wrapper (with more type-safety) is probably your best choice. Alternatively you can also lobby the llvm-dev mailing list for a better C interface, but you will probably have to sign up for maintaining it :-)

-- adrian

> 
>> -- 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
>> 
>> 
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org