[M3devel] LLVM version and patches thereto

[Rodney M. Bates]

On 05/21/2015 05:09 PM, Peter McKinna wrote:
> Hi Rodney,
>
>    Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support.

I have been using llvm 3.4.2, which was the current release when I first started
thinking about this.  I want to avoid overlapping heavy development, while simultaneously
constantly reworking what's already done to new versions.  However, I am well past due to
update to as late a version as reasonable.

They have made a couple of changes that I know will be relevant.  (I've been monitoring
their mailing list--very high traffic.)  One is the metadata class is no longer a subclass
of Value, with various implications to the IR.  Another is that there is only one pointer
type.  It no longer gives its referent type.

We (Peter and I) have duplicated on DIBuilder bindings.  Yours is tidier looking, but mine
is pretty much complete.  I will undertake merging them and adapting to latest llvm.  I had
some real nightmares getting wrap and unwrap unravelled, and will probably have to do some
of that again.

<rant>
IMO, this is, by far, the most extreme specific example I have ever seen for why user-defined
overloading is disastrous idea.  There are a bazillion overloads of wrap and unwrap, whose
declarations are scattered all over the universe.  Figuring out which one you got, or, in
case none was found, where the one you wanted is horrible.  It's further complicated by the fact
that there are various user-defined implicit conversions that the compiler can insert with
no syntactic clue in the call you are trying to decrypt.  These are just as spread out, maybe
more.  And have you ever tried to construct a transitive #include closure in something as big
as llvm?
</rant>

>    Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful.
>    Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future.
>
> Regards Peter
>
> On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote:
>
>     Peter, what version of llvm are you using?  Also, can you tell us what the patches
>     you have made to it are?  Have you sent these to the llvm developers to incorporate?
>     I can guess one is to tolerate DW_LANG_Modula3.
>
>
>     --
>     Rodney Bates
>     rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>
>

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