I am not sure why this occurs either, it only appears that after the
assignment, `old_loop_target` and `loop_target` are both referencing the
same variable, causing the next line to set both variables as None.
Previously, the final value of the target expression would be one after
the last element of the loop, which does not match Python's behavior.
This commit fixes this problem while also preserving the last assigned
value of the loop beyond the loop, matching Python's behavior.
The current default prefix is only derived from the instruction type,
which is not helpful during the comprehension of the IR. Changing to
anonymous names (e.g. %1) helps understand that the variable is only
needed as part of a larger (possibly named) expression.
Because it is unclear which variables are expressions and
subexpressions, all variables which are previously anonymous are named
using (1) the control flow statement if available, (2) the possible name
of the variable as inferred from the variable name in Rust, and (3) the
"addr" prefix to indicate that the values are pointers. These three
strings are joint together using '.', forming "for.i.addr" for instance.
- No longer check if the statement will return. Instead, we check if
the current basic block is terminated, which is simpler and handles
exception/break/continue better.
- Use invoke statement when unwind is needed.
- Moved codegen for a block of statements into a separate function.
- Added `Exception` primitive type and some builtin exception types.
Note that all exception types share the same layout, and should
inherit from the base `Exception` type. There are some hacks in the
toplevel module for handling exception types, we should revisit and
fix them later.
- Added new primitive types to concrete type module, otherwise there
would be some weird type errors.
- Changed the representation of strings to CSlice<u8>, instead of
CString.
Behavior of parallel and sequential:
Each function call (indirectly, can be inside a sequential block) within a parallel
block will update the end variable to the maximum now_mu in the block.
Each function call directly inside a parallel block will reset the timeline after
execution. A parallel block within a sequential block (or not within any block) will
set the timeline to the max now_mu within the block (and the outer max now_mu will also
be updated).
Implementation: We track the start and end separately.
- If there is a start variable, it indicates that we are directly inside a
parallel block and we have to reset the timeline after every function call.
- If there is a end variable, it indicates that we are (indirectly) inside a
parallel block, and we should update the max end value.
Note: requires testing, it is difficult to inspect the output IR
David Mak
Sebastien Bourdeauducq
ychenfo
pca006132