From rodney.m.bates at acm.org Fri Nov 6 03:12:40 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Thu, 05 Nov 2015 18:12:40 -0800 Subject: [M3commit] [modula3/cm3] 322694: Rework llvmbindings to circumvent ABI incompatibil... Message-ID: <563c0c9813b79_597f3fd1828bb29c25221@hookshot-fe1-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 3226946218e5e14f352e25fe441c863b917bbc30 https://github.com/modula3/cm3/commit/3226946218e5e14f352e25fe441c863b917bbc30 Author: Rodney Bates Date: 2015-11-05 (Thu, 05 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 M m3-sys/llvmbindings/src/LLVMTypes.i3 M m3-sys/llvmbindings/src/M3DIBuilder.cpp M m3-sys/llvmbindings/src/M3DIBuilder.h M m3-sys/llvmbindings/src/M3DIBuilder.i3 Log Message: ----------- Rework llvmbindings to circumvent ABI incompatibilities. An unpleasant discovery: Even a struct/record with only one field that is a pointer, is passed by value and returned in ways that are incompatible at the machine level between gcc/clang C/C++ code (these appear to be the same) and cm3 Modula-3 code, using the gcc-derived back end, at least on AMD64_LINUX. Other targets and compiler combinations are possibly also incompatible. llvm's DIBuilder nodes are just such structs, and were being passed by value, to avoid having to deal with copying and allocation/freeing of copies. In this change, the struct/record surrounding is removed and the enclosed pointer alone is passed. Additionally, a couple of structs with two fields are changed to be passed by reference, similar to other existing cases. From rodney.m.bates at acm.org Sun Nov 8 21:42:30 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Sun, 08 Nov 2015 12:42:30 -0800 Subject: [M3commit] [modula3/cm3] 1167a8: Fix segfault starting in M3CG_LLVM.DebugVar, found... Message-ID: <563fb3b647ec0_c5f3fa4bcb592bc47024@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 1167a8a7c4d2a41aabaa8d16e7bc03e2ec1c0672 https://github.com/modula3/cm3/commit/1167a8a7c4d2a41aabaa8d16e7bc03e2ec1c0672 Author: Rodney Bates Date: 2015-11-08 (Sun, 08 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Fix segfault starting in M3CG_LLVM.DebugVar, found in p053 Wrong type of object was being passed to LLVMSetInstDebugLocation. This is probably something that was undermined by llvm's big rework of DIBuilder. From rodney.m.bates at acm.org Mon Nov 9 04:19:01 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Sun, 08 Nov 2015 19:19:01 -0800 Subject: [M3commit] [modula3/cm3] 1052a2: Put constructed name for gobal constant segment in... Message-ID: <564010a58ddbc_795e3fea5514529c17337@hookshot-fe1-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 1052a2e942eefebc4a813183ed41235eccf8a15e https://github.com/modula3/cm3/commit/1052a2e942eefebc4a813183ed41235eccf8a15e Author: Rodney Bates Date: 2015-11-08 (Sun, 08 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Put constructed name for gobal constant segment in its global variable. The global constant segment comes from the front end with no name, in the declare_segment operator. M3CG_LLVM was already concocting a name for it ("M_Const"), but not storing it in the variable for the segment, leading to a NIL segfault later, when handling the end_init operator, in DebugGlobals, while calling M3DIB.DIBcreateGlobalVariable. From rodney.m.bates at acm.org Thu Nov 12 03:38:21 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Wed, 11 Nov 2015 18:38:21 -0800 Subject: [M3commit] [modula3/cm3] 01b944: More work on loophole, to match what llvm expects. Message-ID: <5643fb9dac564_561c3f9a5ee632b81138e0@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 01b944f321ca926ff286d65c3b2d8f1973a64822 https://github.com/modula3/cm3/commit/01b944f321ca926ff286d65c3b2d8f1973a64822 Author: Rodney Bates Date: 2015-11-11 (Wed, 11 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- More work on loophole, to match what llvm expects. From rodney.m.bates at acm.org Fri Nov 13 02:22:56 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Thu, 12 Nov 2015 17:22:56 -0800 Subject: [M3commit] [modula3/cm3] 4cb80a: Progress reworking recognition of front-end's stat... Message-ID: <56453b707f0ff_6a2b3fddcd6cf29c46412@hookshot-fe6-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 4cb80aaf011ff56fc9b3ffdb497dfaa9f4412c56 https://github.com/modula3/cm3/commit/4cb80aaf011ff56fc9b3ffdb497dfaa9f4412c56 Author: Rodney Bates Date: 2015-11-12 (Thu, 12 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Progress reworking recognition of front-end's static link formals. The old scheme failed to recognize when CG did provide a static link formal explicitly, leading to a NIL deref in p140. This still appears to be fooled by p035. From rodney.m.bates at acm.org Fri Nov 20 18:57:29 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Fri, 20 Nov 2015 09:57:29 -0800 Subject: [M3commit] [modula3/cm3] cc2881: Comment about keeping M3 & C++ enum in sync. Message-ID: <564f5f0951a3f_6693fdaaf1f92c092982@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: cc2881b0899ecc1216bfec8a6ff15cc29f5d5f5c https://github.com/modula3/cm3/commit/cc2881b0899ecc1216bfec8a6ff15cc29f5d5f5c Author: Rodney Bates Date: 2015-11-19 (Thu, 19 Nov 2015) Changed paths: M m3-sys/llvmbindings/src/LLVM.i3 Log Message: ----------- Comment about keeping M3 & C++ enum in sync. Commit: e05671e1b6fb8a1d5ae459a2da26289db5ca1d5a https://github.com/modula3/cm3/commit/e05671e1b6fb8a1d5ae459a2da26289db5ca1d5a Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Further try at getting FINALLY static links sorted out. For most procedures, CG emits neither a static link formal nor an actual for it in a call. Backend must insert this stuff, detecting whether the proc is nested, etc. For an internally-generated FINALLY procedure, CG emits an explicit formal for a static link, but does not emit an actual parameter for in it a call. CG does explicitly pass the SL to the runtime, when pushing a finally frame, and this SL will be passed by the runtime when it calls the FINALLY procedure. This fixes execution runtime failures in p014, p035, p045, p048, p079, p140, and p210. Compare: https://github.com/modula3/cm3/compare/4cb80aaf011f...e05671e1b6fb From rodney.m.bates at acm.org Fri Nov 20 23:36:27 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Fri, 20 Nov 2015 14:36:27 -0800 Subject: [M3commit] [modula3/cm3] ea19a4: Further try on FINALLY static links. Also LOOPHOL... Message-ID: <564fa06b2d52c_13053fb4aac272b81785b@hookshot-fe5-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: ea19a440682108f1bf4b9f2fa3540dab2bea9c6c https://github.com/modula3/cm3/commit/ea19a440682108f1bf4b9f2fa3540dab2bea9c6c Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Further try on FINALLY static links. Also LOOPHOLE Fixes. For most procedures, CG emits neither a static link formal nor an actual for it in a call. Backend must insert this stuff, detecting whether the proc is nested, etc. For an internally-generated FINALLY procedure, CG emits an explicit formal for a static link, but does not emit an actual parameter for in it a call. CG does explicitly pass the SL to the runtime, when pushing a finally frame, and this SL will be passed by the runtime when it calls the FINALLY procedure. This fixes execution runtime failures in p014, p035, p079, p140. Also some fixes for LOOPHOLE, to conform to llvm's system of casts. Commit: ae305a8c6249660b234f9222e165543e1a43be7d https://github.com/modula3/cm3/commit/ae305a8c6249660b234f9222e165543e1a43be7d Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Log Message: ----------- Merge branch 'master' of https://github.com/modula3/cm3 Compare: https://github.com/modula3/cm3/compare/e05671e1b6fb...ae305a8c6249 From rodney.m.bates at acm.org Mon Nov 30 22:00:12 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Mon, 30 Nov 2015 13:00:12 -0800 Subject: [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... Message-ID: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: b3c18e6125d3ade015400c8e1fe9febdebc597a2 https://github.com/modula3/cm3/commit/b3c18e6125d3ade015400c8e1fe9febdebc597a2 Author: Rodney Bates Date: 2015-11-30 (Mon, 30 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Rework indirect calls to possibly nested procedures. Fixes p045 and p048. p140 has regressed. This was very tricky. There is a big semantic mismatch between CM3 CG's IR and llvm's, for indirect calls. In CM3, parameters are passed by separate operators, and the call operator just transfers control. So it is possible to have two different parameter-passing sequences, one with and one without a static link, selected at runtime, merging to a single call operator. The selection depends on whether the procedure variable is a closure (implies call a nested procedure) or not (implies call a top-level procedure). In llvm, the actual parameter list is part of the call operator, which denotes the number and llvm types of all the parameters. Thus, two different calls are needed, in two different basic blocks. Moreover, the CM3 IR does not provide the needed information where it is needed. Actual passing of the static link is denoted by a pop_static_link operator, but evaluation of the SL value is done by general-purpose operators such as load, etc., that do not give any indication what they are computing. By the time we see the pop_static_link, these have passed. But the code address to call to, result type, and calling convention (not currently used, but needs to be kept available for the future) are not there. The result type could be saved from the start_call_indirect, but the calling convention is not there either. When we see the call_indirect operator, the static link value has been computed and we can, at compile-time, find its llvm variable, but it is computed in a different basic block and is not available at runtime. We can jump around among basic blocks at compile time, but llvm's SSA and dominator rules mean we can't use it. Moreover, CM3's seemingly nice idea of making IR operators method calls makes it very awkward to do idiom recognition or state-dependent handling of general-purpose operators. The solution used here involves waiting until we get the call_indirect operator, then doing idiom recognition on the llvm code already produced by the general-purpose operations to compute the static link, backing up from there and finding the procedure pointer to recompute the code address. We put this back in the basic block where the pop_static_link is located, then generate the nested indirect call there. The other code, in the wrong place for this scheme, is isolated into an unreachable basic block, which, presumably, llvm will remove. Moreover, if this is a function being called, the two calls produce their function results in two different basic blocks. This is handled by manually constructing a phi node in the block where the paths merge. Phi nodes are usually only constructed internally by llvm. From rodney.m.bates at acm.org Fri Nov 6 03:12:40 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Thu, 05 Nov 2015 18:12:40 -0800 Subject: [M3commit] [modula3/cm3] 322694: Rework llvmbindings to circumvent ABI incompatibil... Message-ID: <563c0c9813b79_597f3fd1828bb29c25221@hookshot-fe1-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 3226946218e5e14f352e25fe441c863b917bbc30 https://github.com/modula3/cm3/commit/3226946218e5e14f352e25fe441c863b917bbc30 Author: Rodney Bates Date: 2015-11-05 (Thu, 05 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 M m3-sys/llvmbindings/src/LLVMTypes.i3 M m3-sys/llvmbindings/src/M3DIBuilder.cpp M m3-sys/llvmbindings/src/M3DIBuilder.h M m3-sys/llvmbindings/src/M3DIBuilder.i3 Log Message: ----------- Rework llvmbindings to circumvent ABI incompatibilities. An unpleasant discovery: Even a struct/record with only one field that is a pointer, is passed by value and returned in ways that are incompatible at the machine level between gcc/clang C/C++ code (these appear to be the same) and cm3 Modula-3 code, using the gcc-derived back end, at least on AMD64_LINUX. Other targets and compiler combinations are possibly also incompatible. llvm's DIBuilder nodes are just such structs, and were being passed by value, to avoid having to deal with copying and allocation/freeing of copies. In this change, the struct/record surrounding is removed and the enclosed pointer alone is passed. Additionally, a couple of structs with two fields are changed to be passed by reference, similar to other existing cases. From rodney.m.bates at acm.org Sun Nov 8 21:42:30 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Sun, 08 Nov 2015 12:42:30 -0800 Subject: [M3commit] [modula3/cm3] 1167a8: Fix segfault starting in M3CG_LLVM.DebugVar, found... Message-ID: <563fb3b647ec0_c5f3fa4bcb592bc47024@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 1167a8a7c4d2a41aabaa8d16e7bc03e2ec1c0672 https://github.com/modula3/cm3/commit/1167a8a7c4d2a41aabaa8d16e7bc03e2ec1c0672 Author: Rodney Bates Date: 2015-11-08 (Sun, 08 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Fix segfault starting in M3CG_LLVM.DebugVar, found in p053 Wrong type of object was being passed to LLVMSetInstDebugLocation. This is probably something that was undermined by llvm's big rework of DIBuilder. From rodney.m.bates at acm.org Mon Nov 9 04:19:01 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Sun, 08 Nov 2015 19:19:01 -0800 Subject: [M3commit] [modula3/cm3] 1052a2: Put constructed name for gobal constant segment in... Message-ID: <564010a58ddbc_795e3fea5514529c17337@hookshot-fe1-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 1052a2e942eefebc4a813183ed41235eccf8a15e https://github.com/modula3/cm3/commit/1052a2e942eefebc4a813183ed41235eccf8a15e Author: Rodney Bates Date: 2015-11-08 (Sun, 08 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Put constructed name for gobal constant segment in its global variable. The global constant segment comes from the front end with no name, in the declare_segment operator. M3CG_LLVM was already concocting a name for it ("M_Const"), but not storing it in the variable for the segment, leading to a NIL segfault later, when handling the end_init operator, in DebugGlobals, while calling M3DIB.DIBcreateGlobalVariable. From rodney.m.bates at acm.org Thu Nov 12 03:38:21 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Wed, 11 Nov 2015 18:38:21 -0800 Subject: [M3commit] [modula3/cm3] 01b944: More work on loophole, to match what llvm expects. Message-ID: <5643fb9dac564_561c3f9a5ee632b81138e0@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 01b944f321ca926ff286d65c3b2d8f1973a64822 https://github.com/modula3/cm3/commit/01b944f321ca926ff286d65c3b2d8f1973a64822 Author: Rodney Bates Date: 2015-11-11 (Wed, 11 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- More work on loophole, to match what llvm expects. From rodney.m.bates at acm.org Fri Nov 13 02:22:56 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Thu, 12 Nov 2015 17:22:56 -0800 Subject: [M3commit] [modula3/cm3] 4cb80a: Progress reworking recognition of front-end's stat... Message-ID: <56453b707f0ff_6a2b3fddcd6cf29c46412@hookshot-fe6-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 4cb80aaf011ff56fc9b3ffdb497dfaa9f4412c56 https://github.com/modula3/cm3/commit/4cb80aaf011ff56fc9b3ffdb497dfaa9f4412c56 Author: Rodney Bates Date: 2015-11-12 (Thu, 12 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Progress reworking recognition of front-end's static link formals. The old scheme failed to recognize when CG did provide a static link formal explicitly, leading to a NIL deref in p140. This still appears to be fooled by p035. From rodney.m.bates at acm.org Fri Nov 20 18:57:29 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Fri, 20 Nov 2015 09:57:29 -0800 Subject: [M3commit] [modula3/cm3] cc2881: Comment about keeping M3 & C++ enum in sync. Message-ID: <564f5f0951a3f_6693fdaaf1f92c092982@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: cc2881b0899ecc1216bfec8a6ff15cc29f5d5f5c https://github.com/modula3/cm3/commit/cc2881b0899ecc1216bfec8a6ff15cc29f5d5f5c Author: Rodney Bates Date: 2015-11-19 (Thu, 19 Nov 2015) Changed paths: M m3-sys/llvmbindings/src/LLVM.i3 Log Message: ----------- Comment about keeping M3 & C++ enum in sync. Commit: e05671e1b6fb8a1d5ae459a2da26289db5ca1d5a https://github.com/modula3/cm3/commit/e05671e1b6fb8a1d5ae459a2da26289db5ca1d5a Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Further try at getting FINALLY static links sorted out. For most procedures, CG emits neither a static link formal nor an actual for it in a call. Backend must insert this stuff, detecting whether the proc is nested, etc. For an internally-generated FINALLY procedure, CG emits an explicit formal for a static link, but does not emit an actual parameter for in it a call. CG does explicitly pass the SL to the runtime, when pushing a finally frame, and this SL will be passed by the runtime when it calls the FINALLY procedure. This fixes execution runtime failures in p014, p035, p045, p048, p079, p140, and p210. Compare: https://github.com/modula3/cm3/compare/4cb80aaf011f...e05671e1b6fb From rodney.m.bates at acm.org Fri Nov 20 23:36:27 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Fri, 20 Nov 2015 14:36:27 -0800 Subject: [M3commit] [modula3/cm3] ea19a4: Further try on FINALLY static links. Also LOOPHOL... Message-ID: <564fa06b2d52c_13053fb4aac272b81785b@hookshot-fe5-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: ea19a440682108f1bf4b9f2fa3540dab2bea9c6c https://github.com/modula3/cm3/commit/ea19a440682108f1bf4b9f2fa3540dab2bea9c6c Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Further try on FINALLY static links. Also LOOPHOLE Fixes. For most procedures, CG emits neither a static link formal nor an actual for it in a call. Backend must insert this stuff, detecting whether the proc is nested, etc. For an internally-generated FINALLY procedure, CG emits an explicit formal for a static link, but does not emit an actual parameter for in it a call. CG does explicitly pass the SL to the runtime, when pushing a finally frame, and this SL will be passed by the runtime when it calls the FINALLY procedure. This fixes execution runtime failures in p014, p035, p079, p140. Also some fixes for LOOPHOLE, to conform to llvm's system of casts. Commit: ae305a8c6249660b234f9222e165543e1a43be7d https://github.com/modula3/cm3/commit/ae305a8c6249660b234f9222e165543e1a43be7d Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Log Message: ----------- Merge branch 'master' of https://github.com/modula3/cm3 Compare: https://github.com/modula3/cm3/compare/e05671e1b6fb...ae305a8c6249 From rodney.m.bates at acm.org Mon Nov 30 22:00:12 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Mon, 30 Nov 2015 13:00:12 -0800 Subject: [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... Message-ID: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: b3c18e6125d3ade015400c8e1fe9febdebc597a2 https://github.com/modula3/cm3/commit/b3c18e6125d3ade015400c8e1fe9febdebc597a2 Author: Rodney Bates Date: 2015-11-30 (Mon, 30 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Rework indirect calls to possibly nested procedures. Fixes p045 and p048. p140 has regressed. This was very tricky. There is a big semantic mismatch between CM3 CG's IR and llvm's, for indirect calls. In CM3, parameters are passed by separate operators, and the call operator just transfers control. So it is possible to have two different parameter-passing sequences, one with and one without a static link, selected at runtime, merging to a single call operator. The selection depends on whether the procedure variable is a closure (implies call a nested procedure) or not (implies call a top-level procedure). In llvm, the actual parameter list is part of the call operator, which denotes the number and llvm types of all the parameters. Thus, two different calls are needed, in two different basic blocks. Moreover, the CM3 IR does not provide the needed information where it is needed. Actual passing of the static link is denoted by a pop_static_link operator, but evaluation of the SL value is done by general-purpose operators such as load, etc., that do not give any indication what they are computing. By the time we see the pop_static_link, these have passed. But the code address to call to, result type, and calling convention (not currently used, but needs to be kept available for the future) are not there. The result type could be saved from the start_call_indirect, but the calling convention is not there either. When we see the call_indirect operator, the static link value has been computed and we can, at compile-time, find its llvm variable, but it is computed in a different basic block and is not available at runtime. We can jump around among basic blocks at compile time, but llvm's SSA and dominator rules mean we can't use it. Moreover, CM3's seemingly nice idea of making IR operators method calls makes it very awkward to do idiom recognition or state-dependent handling of general-purpose operators. The solution used here involves waiting until we get the call_indirect operator, then doing idiom recognition on the llvm code already produced by the general-purpose operations to compute the static link, backing up from there and finding the procedure pointer to recompute the code address. We put this back in the basic block where the pop_static_link is located, then generate the nested indirect call there. The other code, in the wrong place for this scheme, is isolated into an unreachable basic block, which, presumably, llvm will remove. Moreover, if this is a function being called, the two calls produce their function results in two different basic blocks. This is handled by manually constructing a phi node in the block where the paths merge. Phi nodes are usually only constructed internally by llvm. From rodney.m.bates at acm.org Fri Nov 6 03:12:40 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Thu, 05 Nov 2015 18:12:40 -0800 Subject: [M3commit] [modula3/cm3] 322694: Rework llvmbindings to circumvent ABI incompatibil... Message-ID: <563c0c9813b79_597f3fd1828bb29c25221@hookshot-fe1-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 3226946218e5e14f352e25fe441c863b917bbc30 https://github.com/modula3/cm3/commit/3226946218e5e14f352e25fe441c863b917bbc30 Author: Rodney Bates Date: 2015-11-05 (Thu, 05 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 M m3-sys/llvmbindings/src/LLVMTypes.i3 M m3-sys/llvmbindings/src/M3DIBuilder.cpp M m3-sys/llvmbindings/src/M3DIBuilder.h M m3-sys/llvmbindings/src/M3DIBuilder.i3 Log Message: ----------- Rework llvmbindings to circumvent ABI incompatibilities. An unpleasant discovery: Even a struct/record with only one field that is a pointer, is passed by value and returned in ways that are incompatible at the machine level between gcc/clang C/C++ code (these appear to be the same) and cm3 Modula-3 code, using the gcc-derived back end, at least on AMD64_LINUX. Other targets and compiler combinations are possibly also incompatible. llvm's DIBuilder nodes are just such structs, and were being passed by value, to avoid having to deal with copying and allocation/freeing of copies. In this change, the struct/record surrounding is removed and the enclosed pointer alone is passed. Additionally, a couple of structs with two fields are changed to be passed by reference, similar to other existing cases. From rodney.m.bates at acm.org Sun Nov 8 21:42:30 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Sun, 08 Nov 2015 12:42:30 -0800 Subject: [M3commit] [modula3/cm3] 1167a8: Fix segfault starting in M3CG_LLVM.DebugVar, found... Message-ID: <563fb3b647ec0_c5f3fa4bcb592bc47024@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 1167a8a7c4d2a41aabaa8d16e7bc03e2ec1c0672 https://github.com/modula3/cm3/commit/1167a8a7c4d2a41aabaa8d16e7bc03e2ec1c0672 Author: Rodney Bates Date: 2015-11-08 (Sun, 08 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Fix segfault starting in M3CG_LLVM.DebugVar, found in p053 Wrong type of object was being passed to LLVMSetInstDebugLocation. This is probably something that was undermined by llvm's big rework of DIBuilder. From rodney.m.bates at acm.org Mon Nov 9 04:19:01 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Sun, 08 Nov 2015 19:19:01 -0800 Subject: [M3commit] [modula3/cm3] 1052a2: Put constructed name for gobal constant segment in... Message-ID: <564010a58ddbc_795e3fea5514529c17337@hookshot-fe1-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 1052a2e942eefebc4a813183ed41235eccf8a15e https://github.com/modula3/cm3/commit/1052a2e942eefebc4a813183ed41235eccf8a15e Author: Rodney Bates Date: 2015-11-08 (Sun, 08 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Put constructed name for gobal constant segment in its global variable. The global constant segment comes from the front end with no name, in the declare_segment operator. M3CG_LLVM was already concocting a name for it ("M_Const"), but not storing it in the variable for the segment, leading to a NIL segfault later, when handling the end_init operator, in DebugGlobals, while calling M3DIB.DIBcreateGlobalVariable. From rodney.m.bates at acm.org Thu Nov 12 03:38:21 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Wed, 11 Nov 2015 18:38:21 -0800 Subject: [M3commit] [modula3/cm3] 01b944: More work on loophole, to match what llvm expects. Message-ID: <5643fb9dac564_561c3f9a5ee632b81138e0@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 01b944f321ca926ff286d65c3b2d8f1973a64822 https://github.com/modula3/cm3/commit/01b944f321ca926ff286d65c3b2d8f1973a64822 Author: Rodney Bates Date: 2015-11-11 (Wed, 11 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- More work on loophole, to match what llvm expects. From rodney.m.bates at acm.org Fri Nov 13 02:22:56 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Thu, 12 Nov 2015 17:22:56 -0800 Subject: [M3commit] [modula3/cm3] 4cb80a: Progress reworking recognition of front-end's stat... Message-ID: <56453b707f0ff_6a2b3fddcd6cf29c46412@hookshot-fe6-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: 4cb80aaf011ff56fc9b3ffdb497dfaa9f4412c56 https://github.com/modula3/cm3/commit/4cb80aaf011ff56fc9b3ffdb497dfaa9f4412c56 Author: Rodney Bates Date: 2015-11-12 (Thu, 12 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Progress reworking recognition of front-end's static link formals. The old scheme failed to recognize when CG did provide a static link formal explicitly, leading to a NIL deref in p140. This still appears to be fooled by p035. From rodney.m.bates at acm.org Fri Nov 20 18:57:29 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Fri, 20 Nov 2015 09:57:29 -0800 Subject: [M3commit] [modula3/cm3] cc2881: Comment about keeping M3 & C++ enum in sync. Message-ID: <564f5f0951a3f_6693fdaaf1f92c092982@hookshot-fe4-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: cc2881b0899ecc1216bfec8a6ff15cc29f5d5f5c https://github.com/modula3/cm3/commit/cc2881b0899ecc1216bfec8a6ff15cc29f5d5f5c Author: Rodney Bates Date: 2015-11-19 (Thu, 19 Nov 2015) Changed paths: M m3-sys/llvmbindings/src/LLVM.i3 Log Message: ----------- Comment about keeping M3 & C++ enum in sync. Commit: e05671e1b6fb8a1d5ae459a2da26289db5ca1d5a https://github.com/modula3/cm3/commit/e05671e1b6fb8a1d5ae459a2da26289db5ca1d5a Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Further try at getting FINALLY static links sorted out. For most procedures, CG emits neither a static link formal nor an actual for it in a call. Backend must insert this stuff, detecting whether the proc is nested, etc. For an internally-generated FINALLY procedure, CG emits an explicit formal for a static link, but does not emit an actual parameter for in it a call. CG does explicitly pass the SL to the runtime, when pushing a finally frame, and this SL will be passed by the runtime when it calls the FINALLY procedure. This fixes execution runtime failures in p014, p035, p045, p048, p079, p140, and p210. Compare: https://github.com/modula3/cm3/compare/4cb80aaf011f...e05671e1b6fb From rodney.m.bates at acm.org Fri Nov 20 23:36:27 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Fri, 20 Nov 2015 14:36:27 -0800 Subject: [M3commit] [modula3/cm3] ea19a4: Further try on FINALLY static links. Also LOOPHOL... Message-ID: <564fa06b2d52c_13053fb4aac272b81785b@hookshot-fe5-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: ea19a440682108f1bf4b9f2fa3540dab2bea9c6c https://github.com/modula3/cm3/commit/ea19a440682108f1bf4b9f2fa3540dab2bea9c6c Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Further try on FINALLY static links. Also LOOPHOLE Fixes. For most procedures, CG emits neither a static link formal nor an actual for it in a call. Backend must insert this stuff, detecting whether the proc is nested, etc. For an internally-generated FINALLY procedure, CG emits an explicit formal for a static link, but does not emit an actual parameter for in it a call. CG does explicitly pass the SL to the runtime, when pushing a finally frame, and this SL will be passed by the runtime when it calls the FINALLY procedure. This fixes execution runtime failures in p014, p035, p079, p140. Also some fixes for LOOPHOLE, to conform to llvm's system of casts. Commit: ae305a8c6249660b234f9222e165543e1a43be7d https://github.com/modula3/cm3/commit/ae305a8c6249660b234f9222e165543e1a43be7d Author: Rodney Bates Date: 2015-11-20 (Fri, 20 Nov 2015) Log Message: ----------- Merge branch 'master' of https://github.com/modula3/cm3 Compare: https://github.com/modula3/cm3/compare/e05671e1b6fb...ae305a8c6249 From rodney.m.bates at acm.org Mon Nov 30 22:00:12 2015 From: rodney.m.bates at acm.org (Rodney Bates) Date: Mon, 30 Nov 2015 13:00:12 -0800 Subject: [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... Message-ID: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> Branch: refs/heads/master Home: https://github.com/modula3/cm3 Commit: b3c18e6125d3ade015400c8e1fe9febdebc597a2 https://github.com/modula3/cm3/commit/b3c18e6125d3ade015400c8e1fe9febdebc597a2 Author: Rodney Bates Date: 2015-11-30 (Mon, 30 Nov 2015) Changed paths: M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 Log Message: ----------- Rework indirect calls to possibly nested procedures. Fixes p045 and p048. p140 has regressed. This was very tricky. There is a big semantic mismatch between CM3 CG's IR and llvm's, for indirect calls. In CM3, parameters are passed by separate operators, and the call operator just transfers control. So it is possible to have two different parameter-passing sequences, one with and one without a static link, selected at runtime, merging to a single call operator. The selection depends on whether the procedure variable is a closure (implies call a nested procedure) or not (implies call a top-level procedure). In llvm, the actual parameter list is part of the call operator, which denotes the number and llvm types of all the parameters. Thus, two different calls are needed, in two different basic blocks. Moreover, the CM3 IR does not provide the needed information where it is needed. Actual passing of the static link is denoted by a pop_static_link operator, but evaluation of the SL value is done by general-purpose operators such as load, etc., that do not give any indication what they are computing. By the time we see the pop_static_link, these have passed. But the code address to call to, result type, and calling convention (not currently used, but needs to be kept available for the future) are not there. The result type could be saved from the start_call_indirect, but the calling convention is not there either. When we see the call_indirect operator, the static link value has been computed and we can, at compile-time, find its llvm variable, but it is computed in a different basic block and is not available at runtime. We can jump around among basic blocks at compile time, but llvm's SSA and dominator rules mean we can't use it. Moreover, CM3's seemingly nice idea of making IR operators method calls makes it very awkward to do idiom recognition or state-dependent handling of general-purpose operators. The solution used here involves waiting until we get the call_indirect operator, then doing idiom recognition on the llvm code already produced by the general-purpose operations to compute the static link, backing up from there and finding the procedure pointer to recompute the code address. We put this back in the basic block where the pop_static_link is located, then generate the nested indirect call there. The other code, in the wrong place for this scheme, is isolated into an unreachable basic block, which, presumably, llvm will remove. Moreover, if this is a function being called, the two calls produce their function results in two different basic blocks. This is handled by manually constructing a phi node in the block where the paths merge. Phi nodes are usually only constructed internally by llvm.