[M3devel] dbxout_static_chain_decl?

[Jay K]

Shouldn't gcc be able to optimize about as well any such transform?
  Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
 
Anyway, ok.
 
There's stuff I have to figure out and understand here either way.
 
Like, does the the static chain "flow" through non-nested calls?
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:27:56 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
>
>
> Argh!!!!!
> No! We don't want to do work in the front-end to get rid of nesting.
> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>
>
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 26 May 2010, at 18:53, Jay K wrote:
>
>
> Rodney, When you get back to it, can you just dig it out of history?
>
>
> I still think we should try to avoid gcc's nested function functionality.
>
>
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
>
>
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
>
>
> ?
>
>
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
>
>
> Maybe a good test of test cases here?
>
>
>
> - Jay
>
>
> ----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
>
> /* Special-purpose function to write stabs for the static_chain_decl.
> So far, this is not working. m3gdb needs the place in the activation
> record where the SL is stored. Right now, the SL is not necessarily
> stored at all, but may just be kept in a register. DECL_RTL and
> DECL_INCOMING_RTL may both have register expressions. But stabs
> entries for register variables, of kind N_RSYM, are currently ignored
> by gdb in dbxread.c, and making it read them could create problems
> elsewhere, because there can be other variables for which both an
> N_RSYM and an N_LSYM stabs entry are created.
> */
> static int
> dbxout_static_chain_decl (tree decl)
>
> It was added 19 months ago by:
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>
> as well, do we need the #if 0 code added then?
>
> - Jay
>
>