[M3devel] reducing our diff to gcc?

[Rodney M. Bates]

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
>