[M3devel] cm3 llvm backend?

[Rodney M. Bates]

On 06/27/2016 01:31 AM, Jay K wrote:
> redirecting...
>
>  > Olaf
>
>> LLVM didn't seem to satisfy M3's needs, however, if I understood Rodney's laments correctl
>

My big lament about llvm regards producing Dwarf debug info.  Having
debug info in this vastly superior format is one of my main reasons
for wanting an llvm back end.  From the llvm documentation, it sounded
like it would do this, including altering debug info as needed to
match any optimizations done.  Then I hit a brick wall, finding out
llvm only handles a severe subset of Dwarf, apparently what they felt
was needed for C & C++.  More below.

>
> I would like to take this up, maybe soon.
>
>
> I do have a bit of an agenda.
> Maybe my priorities are mixed up.
>
>
>   1 Provide a very portable system.
>   2 Provide an easy to install and use system.
>   3 Switch from gcc backend to LLVM backend, at least optionally (i.e. at least
>     for their supported backends).
>   4 Maybe write our own backends.
>
>
> Where is the LLVM support at?
> Mostly working? Barely working?

I could swear I remember getting the llvm back end to recompile
everything in the m3front group twice and converge to identical-sized
compiled code, and that I said so in either a commit message or
an m3devel list post.  But I couldn't find any such statement.

This is on AMD64_LINUX, and if you are careful not to ask m3llvm
for debug info at all.  Otherwise, there are crashes in m3llvm
and/or llc, trying to provide Dwarf.  This is what I was working
on when I made the disappointing discoveries.  If my memory is
correct here, this means the llvm back end is close to usable
for building.

Also, again from memory, I think the llvm back end has no failures
of test cases that do not also fail using m3cg.

There are still other questions, though.  So far, there are no
changes required to the stock llvm version being used (3.6.1)
But it still requires a build of that on the machine where the
M3 compilation is done, and it is big and slow to build.  Lots
of llvm libraries have to be linked in to m3llvm, and separate
executable llc needs to be available.

The llvm folk are constantly making major API changes, with no
explanation other than diffing successive versions of header
files, so there is no practical chance of using whatever llvm
version may be already installed on a particular host machine.

In light of that, I suppose we could fork and modify a specific
version of llvm and put its source code in our own repository,
similar to m3cg.  But maintenance work on llvm is, to my
standards, a real nightmare.  Just about every single identifier
and operator you see involves a needle-in-haystack search to
locate its declaration, which could be just about anywhere,
in order to know what it is.

And no, the names and operator spellings are not close to adequate
to clue you in.  They have gone to every length possible to use
every clever new C++ "feature" that comes out in the latest
C++-<n> standard, which always just increases the complexity
of the search to a declaration.  So I don't fancy doing any of
this.  (BTW, <n>=17 in recent discussions.)

As for the debug info problem, there has been talk in the llvm
list of a rework that allows a front end to directly produce
true Dwarf (presumably not a subset) for type info only, which
would not be changed by optimizations and so llvm would not
need to pass it through in its own, different, representation.
I don't know how far this has gone.

If/when it happens, utilizing it would entail constructing new
bindings to altered llvm APIs.  This in itself is an extremely
tedious and error-prone task that I hoped, after doing it for
llvm 3.6.1, never to repeat.  Moreover, at the C/M3 interface,
there is no type checking possible, so nitty little errors will
only show up as hard-to-diagnose runtime errors.  That is made
even worse by the lack of a debugger that handles both languages.

Or, we could use Dragisha's rtinfo library to get type info for
a debugger from the .M3WEB files, and Dwarf for the rest.  Off
hand, this sounds like the best approach to me.  Stick with
llvm 3.6.1 as long a possible, and avoid more pain.

>
>
> I know LLVM is big and changing, and maybe they don't value
> compatibility of bitcode.

Actually, keeping their bitcode stable across llvm releases is
one place they do talk about compatibility.  But m3llvm uses calls
to llvm APIs to construct llvm IR as in-memory data, then another
call to get llvm to convert it to bitcode.  So bitcode's stability
is irrelevant to us.  I once thought about producing llvm bitcode
directly, but that seems like a pretty big job.  It would, however,
obviate creating most of those wretched bindings.

>
>
> But look at what we have with the gcc backend.
> Even if we didn't have to patch it at all, I expect
> we'd still have to keep and build a local copy.
>
> Perhaps we should just do that?
>
> With LLVM, with its different licensing, perhaps we could
> get our "frontend" merged upstream, but this would
> then give us a compatibility burden in the persisted m3cg.
> Is that ok?
> It is hypothetical at this point.
>
>
> I know everyone here doesn't really like C/C++ (except me).
> And, more significantly, I know the system written in itself
> is a great test case, but I wonder if we shouldn't write a new
> "real" frontend in C or C++, and see if we can't merge that
> upstream with gcc and/or clang.
>
>
> It also worth mentioning that I believe gcc's Ada front end
> is written in Ada -- you don't actually have to write
> the frontend in C/C++ to merge upstream.

Yes, I once worked on this front end.  As I understood, SRC M3
was not merged into gcc only because RMS was annoyed that SRC made
it a separate executable, so its license was not poisoned by GPL.

>
> But there might remain licensing concern.
>
>
>
>   - Jay
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org