source: etc/campbell/dev-notes/2012-11-01-shadowed-function-names.txt

Last change on this file was 2434, checked in by campbell, 7 years ago

Misc notes.

File size: 1.7 KB
1There's a nasty wrinkle in our plan to use function identifiers as cost labels
2for stack space.  The definition of programs we have allows function names to
3shadow one another, with the earlier definition treated as totally irrelevant,
4but still present in the block⇀fundef mapping of the global environment.  This
5is benign in the sense that there's no way to construct a pointer with that
6block, but breaks my attempt to provide a total mapping from blocks which we
7happen to know map to functions to identifiers, because we don't have the
8invariant that the block must have come from an unshadowed function.
10These shadowed definitions are not permitted in standard C, and are rejected
11during the transformation from the parser's output anyway.
13Some possible solutions are:
15 1 quietly drop shadowed functions from the block⇀fundef map when constructing
16   the global environment; not terribly nice as they'll be carried through the
17   whole compiler, but has low impact on everything
18 2 use blocks for the stack cost labels; relies on setting up the environment
19   in the same way each time - would have to be careful with the initialisation
20   code, and reveals the internals a little bit much (that said, the program
21   transformation results essentially do this)
22 3 establish the invariant that shadowed functions' blocks never appear in
23   program executions; probably a lot of work for little gain
24 4 enforce distinct names, either in the program record (and hence on
25   ‘importing’ Clight) or when creating the global environment; the latter may
26   be a nuisance for the back-end because they use it as a total function
27   (whereas the front-end also does initialisation which can already fail).
Note: See TracBrowser for help on using the repository browser.