[M3devel] more flailing on STATIC_CHAIN_EXPR

[Jay K]

Ah. That little clue does help.

gcc notices which locals are used in nested functions.
gcc puts those (or pointers to them) in a local struct.
We want the address of that struct so we can store it elsewhere, in our closure.
  (gcc would store it in a trampoline.)


I do have try some small samples, and compile with cm3cg -y..

Thanks,
 - Jay

----------------------------------------
> Subject: Re: [M3devel] more flailing on STATIC_CHAIN_EXPR
> From: hosking at cs.purdue.edu
> Date: Mon, 31 May 2010 04:26:41 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on. It has been a long while since I looked at this code and I don't remember all the details. If I had some time I could probably dredge it up. But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure. That's why we need an explicit EXPR.
>
> On 30 May 2010, at 20:34, Jay K wrote:
>
>>
>> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>> Not sure the generated code is correct yet, haven't run it.
>> I'll keep digging esp. on the existing errors.
>>
>>
>> However I'm still a bit "confused".
>>
>>
>> What is the point of STATIC_CHAIN_EXPR?
>>
>>
>> I still have to try the man/boy example, sorry and thank you.
>>
>>
>> Back to the question of STATIC_CHAIN_EXPR.
>>
>>
>> I can see it used in tree-nested.
>> So it doesn't seem pointless.
>>
>>
>> However, notice the following:
>> gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>> It knows the function is nested. It figures out what references resolve how.
>> Locals that are referenced by a nested function are put in a local struct.
>> Sometimes by value, sometimes by pointer, depending.
>> Non-local references go through the chain, n levels, etc.
>> I believe it figures out itself to pass the static link.
>> It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
>>
>>
>> Now, the parts that I recognize are less automatic:
>> static link use can't be optimized away, because it is part of function pointer equality.
>> That is what some of our changes to tree-nested are about.
>> Furthermore, if it can't be optimized away, it might also be forced to exist in the first place.
>> Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>>
>>
>> The part in 4.5 that says:
>> DECL_STATIC_CHAIN (decl) = 0;
>>
>>
>> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
>> we can reliably set it in parse.c.
>>
>>
>> One thing I'm sure I'm missing though is indirect calls.
>>> From gcc's point of view, indirect calls never? have a static link?
>> And from ours they always do?
>> ??
>>
>>
>> This must be key. Direct nested calls need no special support.
>> So a lot will just work.
>> And all indirect calls need special support, since they might be to a closure.
>> ?
>>
>>
>> I'll keep trying to understand.
>>
>>
>> I can get stuff to compile by having m3cg_load_static_link just push nul.
>> Feels wrong though. I have to look at the code, but in the RtExFrame example,
>> it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>> seems to contain an extra.
>> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
>> wierd behavior like compiler hanging, busy growing arrays very large.
>>
>>
>> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
>> at least to make it go away, else gimplification reasonably complains that it doesn't
>> know what to do with it.
>>
>>
>> - Jay
>>
>