[M3devel] How to integrate llvm into cm3

[Rodney M. Bates]

On 05/22/2015 03:48 AM, dirk muysers wrote:
> Personally I have a strong dislike towards LLVM.
> 1. You first have to compile the whole tool chain.
> 2. It is a monstrous blob of code, mainly on Windows.
> 3. Contrary to a widespread belief, It is definitely NOT platform independent.
> 4. It changes at every release.
> 5. Having built your objects, you still have to run them through a platform assembler-linker.

Having grubbed around in it a bit, I can't say I'm exactly ecstatic about llvm.
However, its developers have at least adopted the intention of providing clear
documentation.  While the documentation has trapped/misled me in some areas, this
is dramatically better than gcc, where, as I understand, there is intentional
avoidance of documenting internal formats and data structures, as a way to make it
difficult to work on for any but programmers who are both very skilled and have
a lot of time to spend on it.  Further, it appears gcc changes about as fast as
llvm.


> If I still had the energy of my younger years I would try to pack the platform
> dependent part of the libraries into a dynamic load library together with a JIT
> translator (e.g. libjit) for the portable application code and have a single byte-code
> producing compiler backend.

I don't think things like this are at all unrealistic, if we get a basic llvm
backend developed.

> *From:* Jay K <mailto:jay.krell at cornell.edu>
> *Sent:* Friday, May 22, 2015 2:57 AM
> *To:* Elmar Stellnberger <mailto:estellnb at elstel.org> ; rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org> ; m3devel <mailto:m3devel at elegosoft.com>
> *Subject:* Re: [M3devel] How to integrate llvm into cm3
> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends.
>
> "external" is good for developing backends. You can "snapshot" the state of things
> slightly into the pipeline and then just iterate on later parts.
>
> At the cost of having all the serialization code.
>
> "integrated" is usually preferable for performance, for users.
>
> E.g. NTx86 backend has been sitting in there for decades unused by half the users.
>
> Having extra backends sitting in there unused is ok.
> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho.
> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't.
>
> Everything is demand paged so there is cost to distribute over the network
> and copy around, but at runtime, the pages just sit mostly cold on disk.
>
> One difficulty though is the need to have and build the LLVM code.
> For that reason, delayload-dynamically-linked might be preferable.
> It depends on how small/easy-to-build LLVM is.
>
> I guess LLVM provides more choices than before.
> In order of efficiency and inverse order of debuggability:
>    1 We could construct LLVM IR in memory and run LLVM in-proc and write .o.
>    2 We could write out LLVM bytes and run an executable.
>    3 We could write out LLVM text and run an executable.
>
>  > My personal preference would be to only have one default target statically compiled in
> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR.
> And I don't think LLVM works that way, does it?
> I like one compiler to have all targets and just select with a command line switch.
> I don't like how hard it is to acquire various cross-toolschains.
> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline,
> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a".
>
> binutils at least has this "all" notion reasonably well working now I believe.
> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all.
> And the largely wasted bloat.
> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets.
> There is work to do there..not easy..and no progress lately.
> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding...
>
> - Jay
>
>
>
>
>  > Date: Thu, 21 May 2015 20:13:18 +0200
>  > From: estellnb at elstel.org
>  > To: rodney.m.bates at acm.org; m3devel at elegosoft.com
>  > Subject: Re: [M3devel] How to integrate llvm into cm3
>  >
>  > Am 21.05.15 um 19:24 schrieb Rodney M. Bates:
>  > >
>  > > 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.
>  > >
>  >
>  > Why not put each backend into a shared library and load it dynamically?
>  > Are there still problems with shared libraries for some build targets?
>  > On the other hand having cm3-IR handy and being able to translate
>  > cm3-IR by an executable like m3cc into any desired target has proven
>  > to be very handy for debugging as well as chocking the Modula-3
>  > compiler on a new platform.
>  > My personal preference would be to only have one default target
>  > statically compiled in namely that on for cm3-IR and load all other
>  > targets by a shared libarary dynamically. If that should fail for some
>  > reason one can still use m3cc or one of its counterparts to
>  > accomplish the translation process.
>  >
>  > Elmar
>  >
>  >
>  >
>  >
>  >
>  >

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