[M3devel] reducing our diff to gcc?

[Jay K]

 > 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.
 

 > 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?)



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


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.

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.
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
> >