<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>I understand your dilemas.</div><div>Static linking vs. dynamic.</div><div>Cloning the source or not.</div><div>Significantly growing our repository or not.</div><div>Forking or not -- do we need any patches? Hopefully not but ok if we do.</div><div><br></div><div><br></div><div>Clearly the C backend cheats -- the C compiler appears on the system</div><div>as if by magic, or various external means.</div><div><br></div><div><br></div><div>I am somewhat keen on seeing this LLVM stuff work.</div><div>And somewhat interested in helping.</div><div><br></div><div><br></div><div>First, you know, there are many sayings and their redundancies and opposites:</div><div><br></div><div> 1a too many cooks spoil the broth</div><div> 1b 9 women cannot have a baby in one month (but they can have 9 in 9)</div><div><br></div><div> 2 more/many hands make less/little work</div><div> </div><div>Which is it here, 1 or 2?</div><div>i.e. do you need/want help?</div><div><br></div><div> </div><div>I have built LLVM now a few times.</div><div>Yes it is large and takes time.</div><div>Do we have any required patches for it?</div><div>I'm still on the fence as to if we should "import" it, vs. depend on its presence</div><div>"somehow".</div><div><br></div><div>If there really is version sensitivity, that argues for importing.</div><div>While "apt-get install llvm" might be in widespread availability,</div><div>the exact "apt-get install llvm-3.5.0" I imagine isn't.</div><div><br></div><div><br></div><div>The current setup obviously needs work.</div><div>I'll likely commit something at least a little better.</div><div><br></div><div>Do we really need 3.5.0, or can I use 3.5.2?</div><div><br></div><div><br></div><div> > So I will be upgrading asap. I am always a bit wary of upgrading seeing the</div><div> > problems other people have had, guess I will have to trust upgrade.py.</div><div> </div><div><br></div><div> Really, I run this stuff all the time.</div><div> On various hosts.</div><div> What you/we/I do need though is a safe way to rebuild the compiler</div><div> when it might be buggy. I have ways, but they aren't great/known/easy/incrmental.</div><div> In particular, if you have an ABI change, you need two different m3cores.</div><div> The one for the working compiler and the one for the new compiler.</div><div> Maybe I just need to use "buildlocal" more.</div><div> It doesn't help that the C backend isn't ABI compatible with cm3cg, due to</div><div> nested functions and static links. cm3cg uses a target-dependent extra</div><div> register not accessible to C as far as I know. C backend uses an extra</div><div> last parameter.</div><div><br></div><div> </div><div> - Jay</div><br><br><br><br><div>> Date: Sat, 29 Aug 2015 13:54:46 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: peter.mckinna@gmail.com; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Modula-3 llvm backend<br>> <br>> <br>> <br>> On 08/29/2015 06:02 AM, Peter McKinna wrote:<br>> > Hi Rodney,<br>> > 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.<br>> ><br>> <br>> If nobody objects, I would like to start working on the 3.6.1 version (see below) now,<br>> instead of the 3.5.0.<br>> <br>> > 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.<br>> ><br>> <br>> upgrade.py worked OK for me after I went back to the release compiler and did it<br>> from there, which is the case we really care about. Llvm changes themselves should<br>> not affect the upgrade process, since no llvm mode is used in building the distribution.<br>> <br>> > 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.<br>> ><br>> <br>> I did new bindings for Core and DIBuilder for llvm 3.6.1. This was a big pain. llvm<br>> changed the debug info data structure design to make it not derived from Value. Not only<br>> did it mean lots of binding work, but the client code in M3CG_LLVM needed many changes,<br>> though systematic and simple. These are in separate M3 package llvmbindings. In the<br>> case of DIBuilder, I made the binding pretty much complete for what is in llvm, rather<br>> than just what is currently used.<br>> <br>> I still am uncomfortable about how the complex C++ type hierarchies should be<br>> reflected in the bindings. I doesn't look feasible to reflect these into true<br>> M3 hierarcharies. But clients need some kind of conversions. Some functions<br>> return results that need to be passed back in later, but to a parameter having<br>> a static subtype or supertype thereof. The unwrap functions used in llvm appear<br>> to sometimes just silently convert (the equivalent of) failing NARROWs into NIL<br>> pointers, rather than runtime errors. This will inevitably make some bugs much<br>> harder to track down. I'm not even sure dynamic type checks alway happen. Maybe<br>> some undetected type errors can propagate into C++ and give inscrutable segfaults.<br>> <br>> I am hoping future llvm releases will not affect this so much. They do change things<br>> a lot. I also like to avoid chasing the new releases too often. Just as I was getting<br>> llvmbindings to link with 3.6.1, out came 3.6.2, and now 3.7 is looming.<br>> <br>> I have committed an entirely new package named llvm3.6.1, that uses llvmbindings.<br>> This all compiled and linked, as last I checked, but I have done very little execution<br>> checking. These do require getting some llvm stuff in the right places and states.<br>> I have had similar frustrations as Jay has with trying to use git branches, so<br>> for now, I just made this a separate package. They generate alternative executables<br>> with comparable function, so should be easy to switch between.<br>> <br>> Eventually, we will have to decide what to do about getting needed llvm stuff in,<br>> in a standard place and also, how much work will be done outside of the cm3 build<br>> system. Getting a stable copy of llvm stuff inside cm3, as we now do with gcc/m2cc<br>> would be cleanest for users, but it is very big, takes hours to compile, and maybe<br>> not everybody will want to use it badly enough to pay that price. Right now, you<br>> have to do building and installing of llvm on the side, then edit a few paths in<br>> m3makefiles.<br>> <br>> Keeping m3llvm as a completely separate executable means those who don't want to use<br>> it can be unbothered. With its still being in major development, this seems best<br>> for now. I originally set out on the path of having the functions of m3llvm linked<br>> in to cm3, as with the C backend, but am skeptical about all the llvm libraries that<br>> have to be built and linked in.<br>> <br>> <br>> <br>> > 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.<br>> ><br>> <br>> Those things will take some work, but should not be conceptually difficult.<br>> <br>> > 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.<br>> ><br>> > 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.<br>> ><br>> > Anyway great work. I'm trying to upgrade the opengl bindings to 4.5 and build some test programs. All good fun.<br>> ><br>> > Regards Peter<br>> ><br>> <br>> <br>> <br>> ><br>> > On Sat, Aug 29, 2015 at 5:52 AM, Rodney M. Bates <rodney_bates@lcwb.coop <mailto:rodney_bates@lcwb.coop>> wrote:<br>> ><br>> > Peter,<br>> ><br>> > How actively are you working on the llvm back end? I don't see a lot of updates to<br>> > the github repository. I have checked in some minor things and think I am about<br>> > ready to do more. But I think it best we keep things merged as much as reasonable.<br>> ><br>> > One change is adding specialized support for calls on alloca. These are very<br>> > recently being generated as library calls by the front end, and come through<br>> > the whole process as link failures. I think it best to detect these and convert<br>> > to llvm alloca instructions. m3cc does something like this now.<br>> ><br>> ><br>> > --<br>> > Rodney Bates<br>> > rodney.m.bates@acm.org <mailto:rodney.m.bates@acm.org><br>> ><br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>