[M3devel] How to integrate llvm into cm3

[dirk muysers]

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.

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.

From: Jay K 
Sent: Friday, May 22, 2015 2:57 AM
To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel 
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
> 
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150522/fb68424d/attachment-0002.html>