[M3commit] [M3devel] [modula3/cm3] e7a87c: Comment no nested calls occur in cm3 IR.
Jay K
jay.krell at cornell.edu
Sat Sep 5 03:51:16 CEST 2015
-unfold_nested_procs is what I'm referring to.
Sorry, I comprehend better now -- "procs" vs. "calls".
nested call:
foo(bar())
unnested call: temp = bar() foo(temp)
nested proc:
void foo(){
void bar() { }}
unnested proc:
void foo(){
}
void bar(){}
And then everything I said. :)I want fewer variables and more constants. :)I want one (or fewer) persisted form of the IR and an ability for a backend to easily transform.I need to push the M3CG_MultiPass stuff around more I think.Then again, the IR doesn't tend to live long and there isn't likely a cause for it to, so variation is ok.The only time it lives long is when iterating tightly on a backend.It could be useful for bootstrapping perhaps, but I think we have a better option already -- C/C++.
- Jay
> Date: Fri, 4 Sep 2015 16:48:42 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] [M3commit] [modula3/cm3] e7a87c: Comment no nested calls occur in cm3 IR.
>
> 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
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20150905/02a86f0a/attachment-0002.html>
More information about the M3commit
mailing list