[M3devel] How to integrate llvm into cm3

[Rodney M. Bates]

I previously made significant changes to cm3 and related, to drive an
llvm backend and have them in a branch.

I added 4 new backend modes.  IntLlvmObj and IntLlvmAsm are "internal",
meaning a complete llvm-derived back end is linked in with cm3, similar
to the x86 internal backend, found in m3back.  Obj/Asm is whether it
produces object modules or assembly code. (I did not set out to use
these, just put them in for completeness.)  ExtLlvmObj and ExtLlvmAsm
are for "external".  In these, a separate executable llvm backend is
used (llc) that reads llvm bitcode, generated by cm3.  The code to
produce the llvm-IR is in a package m3llvmgen.  It links in some amount
of llvm infrastructure to build llvm IR in-memory trees, then write them
to llvm bitcode.

Peter's cm3-IR to llvm-IR conversion is a separately compiled executable,
which differs from both the above organizations.  It relys on cm3's existing
ability to write cm3-IR to a file in binary form.  It reads this
(either binary or text form, with a small code change) and produces
llvm bitcode files.

So, do we have any preference about how to do this.  Code changes to
either read cm3-IR from a binary file, a text file, or get it directly
inside the cm3 executable are nearly trivial.  Just substitute a
different subtype of M3CG.T. to supply the cm3-IR operator stream.
Cm3 changes would be a bit bigger to drive the separate executable pass.

There are pros and cons.  Integrating Peter's cm3-to-llvm conversion into
the cm3 executable would be faster compiling--one fewer time per interface
or module for the OS to create a process and run an executable.  But it
would also entail linking in this code, along with some of llvm's infrastructure,
into cm3, making its executable bigger, with code that might not be executed
at all, when a different backend is used.  We already have the x86 integrated
backend and the C backend linked in to cm3, whether used or not.

Anybody have thoughts on this?  I suppose it could be set up to be fairly
easily changed either way too.


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