One general strategy has been overwhelmingly successful in other areas
of quadcode manipulation. Rather than attempting to add operations
that handle the awkward cases when they are detected, it has been much
easier to generate code for the worst case always, and then optimize
it away. The code for variable accesses, for instance, is truly
horrific when initially generated:

  + test that a variable exists, and throw an error otherwise

  + test that the variable is not an array, and throw an error
    otherwise.

  + test that the value is of an admissible type for the operation
    that will use it, and throw an error otherwise.

  + downcast the value to an instance of the correct type.

  + if the value is used in an arithmetic operation, purify the value,
    that is, extract the machine-native representation.

Nevertheless, all of these tests become redundant if a second access
to the variable is dominated by the first. In that case, partial
redundancy elimination will eliminate all five of these steps and
simply use the pure value in the arithmetic operation. The partial
redundancy elimination is based largely on the value-based algorithms
developed in (LT Simpson's PhD
thesis)[https://www.clear.rice.edu/comp512/Lectures/Papers/SimpsonThesis.pdf].

We therefore assume here that we will take the brutally simple
approach of generating code that:

  + whenever a local variable (whether potentially aliased or not) is
    loaded, generate a `moveFromCallFrame` instruction transferring a
	Tcl value into an SSA value.

  + whenever a local variable (whether potientially aliased or not) is
    stored, generate a `moveToCallFrame` instruction transferring an
    SSA value into a Tcl value.

  + whenever an operation (an invocation, a direct operation, etc.)
    may potentially refer to a local variable or an alias
    thereof. make sure that it has the callframe as one of its inputs.

  + whenever an operation (an invocation, a direct operation, etc.)
    may potentially modify a local variable or an alias thereof,
	make sure that it has the callframe as both an input and an
    output.

  + upon procedure exit (normal or abnormal) make sure that any
    potentially aliased local variables are actually returned to the
    callframe. 

The last three items in the list ensure that we can track
antidependencies correctly; they become dependencies on the callframe
value. This, in turn, will require that we modify the `directSet`,
................................................................................
operation may not be hoisted above a LOAD operation that might refer
to the same memory). His technique also does not contemplate downward
code motion, where a STORE operation that does not affect a loop's
operation might be moved to after the loop exit. To address these
deficiencies, it falls to us to develop a better theory of Tcl
variable accesses.

One general strategy has been overwhelmingly successful in other areas
of quadcode manipulation. Rather than attempting to add operations
that handle the awkward cases when they are detected, it has been much
easier to generate code for the worst case always, and then optimize
it away. The code for variable accesses, for instance, is truly
horrific when initially generated:

  + test that a variable exists, and throw an error otherwise
  
  + test that the variable is not an array, and throw an error
    otherwise.
	
  + test that the value is of an admissible type for the operation
    that will use it, and throw an error otherwise.
	
  + downcast the value to an instance of the correct type.
  
  + if the value is used in an arithmetic operation, purify the value,
    that is, extract the machine-native representation.

Nevertheless, all of these tests become redundant if a second access
to the variable is dominated by the first. In that case, partial
redundancy elimination will eliminate all five of these steps and
simply use the pure value in the arithmetic operation. The partial
redundancy elimination is based largely on the value-based algorithms
developed in [LT Simpson's PhD
thesis][SIMP96]

We therefore assume here that we will take the brutally simple
approach of generating code that:

  + whenever a local variable (whether potentially aliased or not) is
    loaded, generate a `moveFromCallFrame` instruction transferring a
	Tcl value into an SSA value.
	
  + whenever a local variable (whether potientially aliased or not) is
    stored, generate a `moveToCallFrame` instruction transferring an
    SSA value into a Tcl value.
	
  + whenever an operation (an invocation, a direct operation, etc.)
    may potentially refer to a local variable or an alias
    thereof. make sure that it has the callframe as one of its inputs.
	
  + whenever an operation (an invocation, a direct operation, etc.)
    may potentially modify a local variable or an alias thereof,
	make sure that it has the callframe as both an input and an
    output.
	
  + upon procedure exit (normal or abnormal) make sure that any
    potentially aliased local variables are actually returned to the
    callframe. 

The last three items in the list ensure that we can track
antidependencies correctly; they become dependencies on the callframe
value. This, in turn, will require that we modify the `directSet`,
................................................................................
operation may not be hoisted above a LOAD operation that might refer
to the same memory). His technique also does not contemplate downward
code motion, where a STORE operation that does not affect a loop's
operation might be moved to after the loop exit. To address these
deficiencies, it falls to us to develop a better theory of Tcl
variable accesses.

## References

[SIMP96]: <https://www.clear.rice.edu/comp512/Lectures/Papers/SimpsonThesis.pdf>.