[M3devel] Modula-3 llvm backend

[Rodney M. Bates]

On 08/29/2015 06:02 AM, Peter McKinna wrote:
> Hi Rodney,
>    No I havent done much lately. I've reached a point where I was waiting for your stuff to be integrated so I can do some more testing. Which is really good.  I think we need to track down any lurking bugs by building first the test suite and then the runtime and compiler and see if they work.
>

If nobody objects, I would like to start working on the 3.6.1 version (see below) now,
instead of the 3.5.0.

>    So I will be upgrading asap. I am always a bit wary of upgrading seeing the problems other people have had, guess I will have to trust upgrade.py.
>

upgrade.py worked OK for me after I went back to the release compiler and did it
from there, which is the case we really care about.  Llvm changes themselves should
not affect the upgrade process, since no llvm mode is used in building the distribution.

>   As you know llvm 3.7 is on the verge of being released. I would like to upgrade to that release soon as well. How did your attempt to build debug bindings go ? That will be the sticking point in upgrading I think.
>

I did new bindings for Core and DIBuilder for llvm 3.6.1.  This was a big pain.  llvm
changed the debug info data structure design to make it not derived from Value.  Not only
did it mean lots of binding work, but the client code in M3CG_LLVM needed many changes,
though systematic and simple.  These are in separate M3 package llvmbindings.  In the
case of DIBuilder,  I made the binding pretty much complete for what is in llvm, rather
than just what is currently used.

I still am uncomfortable about how the complex C++ type hierarchies should be
reflected in the bindings.  I doesn't look feasible to reflect these into true
M3 hierarcharies.  But clients need some kind of conversions.  Some functions
return results that need to be passed back in later, but to a parameter having
a static subtype or supertype thereof.  The unwrap functions used in llvm appear
to sometimes just silently convert (the equivalent of) failing NARROWs into NIL
pointers, rather than runtime errors.  This will inevitably make some bugs much
harder to track down.  I'm not even sure dynamic type checks alway happen.  Maybe
some undetected type errors can propagate into C++ and give inscrutable segfaults.

I am hoping future llvm releases will not affect this so much.  They do change things
a lot.  I also like to avoid chasing the new releases too often.  Just as I was getting
llvmbindings to link with 3.6.1, out came 3.6.2, and now 3.7 is looming.

I have committed an entirely new package named llvm3.6.1, that uses llvmbindings.
This all compiled and linked, as last I checked, but I have done very little execution
checking.  These do require getting some llvm stuff in the right places and states.
I have had similar frustrations as Jay has with trying to use git branches, so
for now, I just made this a separate package.  They generate alternative executables
with comparable function, so should be easy to switch between.

Eventually, we will have to decide what to do about getting needed llvm stuff in,
in a standard place and also, how much work will be done outside of the cm3 build
system.  Getting a stable copy of llvm stuff inside cm3, as we now do with gcc/m2cc
would be cleanest for users, but it is very big, takes hours to compile, and maybe
not everybody will want to use it badly enough to pay that price.  Right now, you
have to do building and installing of llvm on the side, then edit a few paths in
m3makefiles.

Keeping m3llvm as a completely separate executable means those who don't want to use
it can be unbothered.  With its still being in major development, this seems best
for now.  I originally set out on the path of having the functions of m3llvm linked
in to cm3, as with the C backend, but am skeptical about all the llvm libraries that
have to be built and linked in.



>   As far as debug support goes we are still lacking support for globals , sets, open arrays and hence TEXT and I was planning on asking the llvm people if they had any suggestions.
>

Those things will take some work, but should not be conceptually difficult.

>   We need to get a few parameters into this backend including the data representation string and target triple and maybe others. Also it would be good if one could set whether debug info was generated. Its easier to read assembler with dwarf annotations than stabs however sometimes its nice to remove the clutter. Last I looked you could set the level of debug but not turn it off entirely in the builder.
>
> Also how does one test the atomic instructions? I have never seen them generated. I think the llvm C api needs support for these as well so the point may be moot.  Actually there has been a lot of discussion about the C api recently on the llvm lists so hopefully any changes wont be too radical.
>
> Anyway great work. I'm trying to upgrade the opengl bindings to 4.5 and build some test programs. All good fun.
>
> Regards Peter
>



>
> On Sat, Aug 29, 2015 at 5:52 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote:
>
>     Peter,
>
>     How actively are you working on the llvm back end?  I don't see a lot of updates to
>     the github repository.  I have checked in some minor things and think I am about
>     ready to do more.  But I think it best we keep things merged as much as reasonable.
>
>     One change is adding specialized support for calls on alloca.  These are very
>     recently being generated as library calls by the front end, and come through
>     the whole process as link failures.  I think it best to detect these and convert
>     to llvm alloca instructions.  m3cc does something like this now.
>
>
>     --
>     Rodney Bates
>     rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>
>

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