[M3devel] reducing our diff to gcc?

[Rodney M. Bates]

On 06/11/2012 02:07 PM, Jay K wrote:
>
>   >  Maybe gcc would be easier too, if we didn't do our own debug
>    >  info production in parse.c.
>
> Correct. It is "our fault" for doing wierd things debugging-wise.
>
>   >  That could be a lot of work
>
>
> It is "the right amount of work", but yeah, kind of a lot.
>
>   >  but would fit fit nicely with switching to dwarf.
> We'd just use -g and use whatever gcc wants for the target system.
> Sometimes Dwarf, sometimes not, we wouldn't care.
>

It's going to require quite a lot in m3gdb.  Stock gdb has readers for several
debug info formats, but there's a lot that is language-dependent, even for C,
let alone the other languages supported by stock gdb.  I think this has considerable
debug-format dependency too, leading to a Cartesian product.  It is certainly
that way for Modula-3.  I would be greatly surprised if gcc didn't also require
at least a bit of M3-dependent work, even for dwarf.

>
>   >  As I understood it, all of the changes tree-nested.c makes are really only
>   >  needed for the interaction between nonlocal variable access _and_ inlining.
>
>
> I don't think so, but I don't know.
>
>
>   >  The last I knew we have had inlining disabled from the beginning anyway.
>
>
> We have inlining on mostly. Aside from a small sprinkling of "volatile".
> Off in gcc 4.6 backend, but I never enabled that and am moving on to 4.7 rapidly.
>
>
>   >  what would you think of just disabling what tree-nested does?
> I'm really not sure it is possible.
> Sure, if nested functions used only for "lexical hiding" of the functions themselves.
> But Modula-3 uses the "static link" in a unique-to-itself way.
> I don't expect gcc to "just work".
> I can explain the Modula-3 unique way if people want.
> It turns out..I have thought about this a bunch, there is no good way to handle the static link,
> given that you can take the addresses of nested functions. (Right?)
>

Please elaborate.  Yes, you can take the address of a nested function.  But you can
only pass it as a parameter.  You can't assign it to a variable.  This latter restriction
requires some runtime enforcement, but I think it is taken care of by explicitly
coded runtime checks generated by parse.c or earlier.

The nested-function language extension to C, implemented by stock gcc, allows the taking
of the address of a nested function, without the restriction against assigning it to
a variable, with no linguistic safety added.  If, in C, you use such a function "address"
for a function that has returned, to quote from gcc "all hell will break loose".
But this should imply that stock gcc support is enough for Modula-3.

>
>
> Where you don't take the address, the static link can just be an extra parameter.
>

Either way, you need a static link, and it is just passed as an extra parameter.
In the x86 case, it is always passed in the same register (ecx, if I recall) and
always immediately stored by prolog code at the same place in the AR.  tree-nested
doesn't mess with this, but adds extra static-linkish variable(s) elsewhere in
the AR, derived from this one, and uses them in some/all places.

>
> Or maybe this is dealt with elsewhere or otherwise...
>
>
> We do actually use "extra parameter" sometimes for static link.
> And maybe elsewhere/otherwise is in the frontend, mostly..just mostly...
>
>
> There are comments in tree-nested.c indicating it has "bad history".
> But actually, I'm not sure it does things so poorly.
>

I haven't read the comments in later gcc versions, but the bad history I recall
is that it greatly simplifies an "insanely complicated" scheme.  Unfortunately,
the simplification is all compile-time, at the expense of replacing a relatively
simple runtime scheme with one I would call at least very complicated, if not
insanely so.

> The basic theory of nested functions includes stuffing locals into a struct,
> at least locals accessed by nested functions, and passing a pointer to that struct
> as an extra parameter. The locals include said pointer to struct of locals, in the case
> of multiple nesting levels. OR you can "flatten" things, I guess, maybe.f

Actually, it's the other way around.  All locals start out in a flat AR.  If the
function contains nested function(s), tree-nested collects the locals that are
referenced nonlocally (i.e., from within one of the nested functions) into a local
struct.  Then, the nested functions get and use what you could call a "derived static link"
(a better term is needed) that points directly to this struct rather than to the whole AR.
I guess this helps with inlining, in case the struct isn't actually located in the same way
inside the parent AR.

> Flattening is problematic though, given nested functions can be mutually recursive
> and such..you want to update just one place and have all the other code follow pointers to it.
> Optimization can copy around copies instead of pointers, where it is profitable.
> Sorry, I don't have time to explain right now.
>
>
>   - Jay
>
>
> ----------------------------------------
>> Date: Mon, 11 Jun 2012 07:39:09 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] reducing our diff to gcc?
>>
>>
>>
>> On 06/10/2012 03:34 AM, Jay K wrote:
>>>
>>> reducing our diff to gcc?
>>>
>>>
>>> Ignore my hacking: extern C, removal of optimizer, removal of gmp/mpfr/mpc..
>>>
>>>
>>> but wait: do people like removal of gmp/mpfr/mpc? I do. I'm torn.
>>>
>>> But to my point:
>>>
>>>
>>> gimplify.c: I think we can achieve the diff via langhook.gimplify_expr.
>>>
>>>
>>> tree.def: I think frontends can add their own codes in separate files, so the diff can be removed.
>>>
>>>
>>> but, tree-nested.c, I doubt this can be avoided..so I'm left probably
>>> just not bothering with the others.
>>>
>>
>> tree-nested.c has been a thorn in my side from its inception. I broke a whole
>> lot of stuff in m3gdb, everything that has to do with nonlocal variable access
>> and/or variables of procedure type. It reshuffles the activation record around,
>> with multiple copies of lots of things, especially the static link, which has
>> either two, or, if I remember right, three copies in different places. Moreover,
>> they don't all point to the same place in their target AR.
>>
>> All this wouldn't be too bad, if we got the debug info altered to reflect the
>> reality, but by the time tree-nested does its thing, it's kind of late to do
>> that easily. That's one of the attractions of llvm to me, that it's well set
>> up to transform both the code and its debug info in parallel, when doing
>> optimization. Maybe gcc would be easier too, if we didn't do our own debug
>> info production in parse.c. That could be a lot of work, but would fit
>> fit nicely with switching to dwarf.
>>
>> As I understood it, all of the changes tree-nested.c makes are really only
>> needed for the interaction between nonlocal variable access _and_ inlining.
>> The last I knew we have had inlining disabled from the beginning anyway.
>> Jay, if this is still true, and as you are into disabling various gcc
>> optimizations, what would you think of just disabling what tree-nested does?
>>
>>>
>>> Thoughts?
>>>
>>>
>>> There is also at least one bug fix...that I could avoid needing.
>>> There is a bug optimizing our form of div/mod.
>>> We could avoid that by going back to function calls, but..again, I'm torn.
>>>
>>>
>>> If you configure -enable-checking, at least currently, there are asserts that have to be removed.
>>>
>>>
>>> I think I'll just go ahead and patch 4.7 "completely", w/o overdoing it.
>>>
>>>
>>> - Jay
>>>
>