[M3devel] [M3commit] [modula3/cm3] e7a87c: Comment no nested calls occur in cm3 IR.

[Rodney M. Bates]

Hmm.  As near as I remember, I assumed the front end was unnesting calls just because it
did it on one example (using m3cc).  Looking at the code, I see command line options
-nested_calls and -no_nested_calls (the default).  However, the only use of this I can
find affects whether an independent check by a M3CG_Check.T instance verifies that
there is no nesting.  So it looks like it's actually unconditional after all.  I'll
leave the comments as they are unless this changes.

I would expect a back end not to have to cope with them, unless it was generating
final code for a bytecode or stack-like machine that could directly handle them nested.

On 09/03/2015 05:38 PM, Jay wrote:
> I believe the lack of nested calls is optional. M3front has an option. Different backends have different requirements. The in-process backends could/should set the flag. There should be an M3CG pass or two to transform from either form to the other (or have m3front output one way, and optionally transform to the other).
>
>   - Jay
>
> On Sep 3, 2015, at 12:17 PM, Rodney Bates <rodney.m.bates at acm.org> wrote:
>
>>   Branch: refs/heads/master
>>   Home:   https://github.com/modula3/cm3
>>   Commit: e7a87c74bd1b88d284408b760b22409459640d46
>>       https://github.com/modula3/cm3/commit/e7a87c74bd1b88d284408b760b22409459640d46
>>   Author: Rodney Bates <rodney.m.bates at acm.org>
>>   Date:   2015-09-03 (Thu, 03 Sep 2015)
>>
>>   Changed paths:
>>     M m3-sys/m3middle/src/M3CG_Ops.i3
>>
>>   Log Message:
>>   -----------
>>   Comment no nested calls occur in cm3 IR.
>>
>> Comment the fact that nested calls in source code are unnested in
>> cm3 intermediate representation.  This is an essential invariant
>> to both producers and consumers of this IR.
>>
>> Changes to be committed:
>>
>>     modified:   src/M3CG_Ops.i3
>>
>>
>>   Commit: 8bcccbb7ccaa0af0879c80014215daa571f95174
>>       https://github.com/modula3/cm3/commit/8bcccbb7ccaa0af0879c80014215daa571f95174
>>   Author: Rodney Bates <rodney.m.bates at acm.org>
>>   Date:   2015-09-03 (Thu, 03 Sep 2015)
>>
>>   Changed paths:
>>     M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3
>>
>>   Log Message:
>>   -----------
>>   Revert an incorrect fix due to misdiagnosis.
>>
>> The actual problem here was not a lack of a set_source_file,
>> it was reading binary cm3 IR with the ascii reader.
>>
>> Changes to be committed:
>>
>>     modified:   M3CG_LLVM.m3
>>
>>
>>   Commit: 379f750aa7e5fac4948be06d5bd7a748a7d85350
>>       https://github.com/modula3/cm3/commit/379f750aa7e5fac4948be06d5bd7a748a7d85350
>>   Author: Rodney Bates <rodney.m.bates at acm.org>
>>   Date:   2015-09-03 (Thu, 03 Sep 2015)
>>
>>   Changed paths:
>>     M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3
>>
>>   Log Message:
>>   -----------
>>   Big merge of changes to M3CG_LLVM.m3 from package llvm into package llvm3.6.1
>>
>> Lots of changes happened to this file in package llvm, while the version
>> in package llvm3.6.1 has been undergoing integration with the greatly
>> altered llvm interfaces in llvm 3.6.1.  Merge these into the  M3CG_LLVM.m3
>> found in package llvm3.6.1.  Also some random manual review and fixes.
>>
>> Compiles and runs to completion, with superficially believable output,
>> on one small test case involving separate temporaries in and out of
>> a FINALLY procedure.
>>
>> Works with cm3 command, when its executable m3llvm has been shipped.
>>
>> The test compile fails to link, not finding alloca.  m3llvm needs to
>> detect calls on alloca and translate internally into llvm alloca
>> instructions, rather than letting them through to be linked in.
>>
>> Changes to be committed:
>>
>>     modified:   M3CG_LLVM.m3
>>
>>
>> Compare: https://github.com/modula3/cm3/compare/909637def4c4...379f750aa7e5
>> _______________________________________________
>> M3commit mailing list
>> M3commit at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit
>

-- 
Rodney Bates
rodney.m.bates at acm.org