CFG representation needs type information

[Matt Giuca]

The AST representation carries type information in two ways. Firstly, the type of each variable is known in the localtable. Secondly, each expr has a type.

The CFG representation doesn't carry any type information. The localtable is useless because the variables aren't qualified and there are no temporaries (basically it carries type info for the AST variables, which is a completely different set of variables). And instructions don't carry a type.

This hasn't been a problem so far, but type information will be needed in the CFG for some analysis, as well as code generation.

Either update the localtable in the CFG representation to include the type of every CFG variable, or annotate each instr with the type of the variable it assigns.

[Matt Giuca (mgiuca)]

The CFG representation does actually contain an assoc_list mapping varnames to types. However, it is given the wrong set of variables by ast_cfg.func_body_to_cfg (which simply copies the AST decls over to the CFG). This can be fixed by having ast_cfg create a new decls map involving the types of all of the new CFG variables.

[Matt Giuca (mgiuca)]

Do it the former way -- keep a mapping from varnames to types. It is much more useful to be able to look up the type of a given variable without having to find its instruction (otherwise various backends will need to keep their own variable type table).

However, don't make it an assoc list -- make it an actual map so you can do log(n) lookups. Unfortunately this makes it inconsistent with the AST representation, but that's OK. AST is for the output of the frontend, CFG is for the input to the backend, so that makes sense.

[Matt Giuca (mgiuca)]

Fixed in newtypes branch r1049.

[Matt Giuca (mgiuca)]

Merged to trunk, r1030.