[M3devel] M3CG_LLVM.m3, commit 7eb3628

[Rodney M. Bates]

On 07/19/2017 10:39 PM, Peter McKinna wrote:
> Hi Rodney,
>
>   It's been a while since I did that change and had to refresh my memory. I was getting segv's on some testcases. I'm not entirely sure that change is the correct way to do things and I dont quite understand the theory. Best if I show a small sample of code.
>
> Take this snippet
>

-- snip ---


>>
> END TestNested;
>
> the llvm code produced is (I have pointed out a couple of problems)

Is this llvm code before or after your change?

>
> (excuse the wordiness - we should do something about those long names sometime)
>
> >

I like long names, consistent names, and lots of explicitness in general.  I end up
doing a lot of maintenance work on large code bodies, and usually wish for even
more of this kind of stuff than is there.  I often put in a things that would
have saved me a lot of time tracking down info that is not locally obvious.

>

-- snip ---

> So I think GetAdrofUpLevelVar is getting a value from cumUplevelRefdCt which is always zero since it does not get
> set until end_procedure and then subtracting the stack size leads to negative values.
>

My theory is that GetAdrOfUpLevelVar should not be called until after end_procedure.
I just did a fairly thorough code review, and it looks like this should be true.

> I'm not sure if I have fixed the problem completely but my testcases seem to work. Feel free to change/fix whatever. I certainly think the nested proc side of things was the most complex part of the whole exercise.
>

I regard this display idea, which is not quite like the usual meaning of the term as I
understand it, as a messy hack, but it seemed the easiest way at the time.  It does not
support debugging cleanly at all, since a debugger user can do uplevel references to
variables that are not uplevel referenced in the code.  I'm not sure there is an alternate
way for a debugger at all.

I have two plans for a rework some day.  One is to package the entire activation record
in an explicit llvm struct and use displacements within for all addressing, compiled and
debugger-initiated, uplevel or not.  Then the "static link" would be a real static link
as usually meant by the term.  This would also fit reasonably well with using CG's already
done allocation, instead of letting llvm do it all over again with llvm alloca instructions.
An llvm developer on the llvm mailing list once recommended rather emphatically to me to
*not* llvm do the layout.

The other way is, sometime more recently, a newer version of llvm added an intrinsic or
something that looked like it would allow to get back the displacements that llvm created
for alloca's, so we could compute differences and use them in debug info.  This would
involve going to a newer llvm and thus redoing the DIBuilder binding, re. which, see below ...

> Are you getting back into generating dwarf debug? I wrote a swig module that simplifies generating the di bindings which seemed to work ok. I might put them into git sometime.
>

I am trying to get back to it now.  Creating the DIBuilder binding I did was by far the
absolutely most painful programming task I have ever done, so I am not eager to repeat
it.  Automated binding generation would be a huge relief.  Please make whatever you have
done in this area available.  For what version of llvm are the bindings you did?

> On a separate note, you wouldn't happen to know how to get the gcc backend to generate LTO. It says it's not configured for it but I can't seem to build it with it LTO support. I am trying to build an interface to the AVX builtin functions but I would prefer if they were inlined into M3 code rather than the overhead of a call to a C wrapper.
>

I know very little about this, but I know Jay removed large amounts of unused stuff from
the M3 gcc backend, so maybe the needed code is not there.

> Regards Peter
>
>
> On Wed, Jul 19, 2017 at 11:02 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote:
>
>     Peter, I don't understand the rationale for the change in commit 7eb3628.  For llvm, the front end
>     is set to pull nested procedures out and place them completely after their containing static ancestor.
>     So all uses of a display index will occur after the end of the procedure declaring the
>     uplevel-referenced variable, and the computation of cumUplevelRefdCt, at the end of the
>     outer procedure will be soon enough.
>
>     If it were not so, even this change would not be early enough, because, with Modula-3 having no
>     declare-before-use rule, an uplevel reference can be to a variable declared after the referencing
>     nested procedure.
>
>     Have I missed something?
>     --
>     Rodney Bates
>     rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>
>

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