If you look at the generated code (CompilePrint
, for example), the procedure is as follows:
- All the program's constants are placed into separate registers (regardless of their location in the program, they can be in the r.h.s.of variable initialization in scoping constructs, or they can be statements in their bodies. Actually, same constants found in different part of a program share the same register).
- The variables initialized by
Module
are placed into separate registers, one by one.
This seems quite natural. There is no real need for Compile
to actually implement nested scoping where one and the same variable can be shadowed and take another value in some inner block of code. So, it simply assigns different registers for different Module
variables - which mimics what Module
is doing in the top-level code where it does not really implement nested scoping a-la C, but generates unique symbols, which emulate it.
- The binding semantics for nested scoping seems to be the same as for the top-level, in that the variables in code are bound to the smallest (innermost) scope containing that piece of code.
- It looks like, for the purposes of
Compile
, Block
and Module
are the same (this refers to cases where the code can be fully compiled without callbacks to MainEvaluate
. If such callbacks are present, Block
may behave differently from Module
, if it is a part of the top-level code executed in a callback). In other words, Compile
does not implement dynamic scoping (except via callbacks to the main evaluator), and Block
variables are also bound lexically.
Here is what CompilePrint
gives for your example:
cmp = Compile[{}, Module[{a = 7, b = a}, b + 1]];
Needs["CompiledFunctionTools`"];
CompilePrint[cmp]
No argument
5 Integer registers
Underflow checking off
Overflow checking off
Integer overflow checking on
RuntimeAttributes -> {}
I0 = 7
I3 = 1
Result = I4
1 I1 = I0
2 I2 = I1
3 I4 = I2 + I3
4 Return
and here is a more complicated example including nested Module
-s and local variable naming conflicts:
cmp3 =
Compile[{},
Module[{a = 7, b = a},
b = a + b;
Module[{b = b, a = b + 2}, a + b + 1]]];
CompilePrint[cmp3]
No argument
8 Integer registers
Underflow checking off
Overflow checking off
Integer overflow checking on
RuntimeAttributes -> {}
I4 = 2
I0 = 7
I6 = 1
Result = I7
1 I1 = I0
2 I2 = I1
3 I3 = I1 + I2
4 I2 = I3
5 I3 = I2
6 I5 = I3 + I4
7 I7 = I5 + I3 + I6
8 Return
Analyzing the register allocations in these examples confirms the procedure I suggested above. Given this, it looks like the effect you have noticed can be relied upon (but this has a status of an educated guess only).