Re: Interprocedural SSA form?

  > this depends on what You are planning to do on the interprocedural
  > representation. For a whole-program analysis, we have found the
  > following idea(s) useful:
  >
  > * Formal arguments in procedure f are nothing more than Phi-Functions
  > for the actual parameters given to calls to f in other procedures.


This insight was popularised by Appel: "SSA is functional programming"
in ACM SIGPLAN Notices 33(4), 1998. In fact, Appel goes further and
suggests transforming all control flow into function calls.


  > * Return instructions (with a value) are 'inverse' to the argument
  > Phi's in the sense that the return value of a call to f can be
  > now written as an access to the return value of f.


For languages with indirect function calls, phi functions may be
required for return values from indirect call sites, to merge values
from all possible callee functions. Interprocedural SSA (Liao et al,
PPoPP 1999) handles this.


  > * For a program analysis, you will probably take into account that
  > analysis information gathered for a return instruction must be
  > filtered: if g calls f, and accesses the return instruction of g,
  > it may only pick up information computed from values prpagated into
  > f from g. (if this is omitted, you propagate information along
  > unrealizable paths, e.g. g and g' both call f, and g' values are
  > propagated int the call to f, through f, and back ... into g'.)


This is the issue of context-sensitivity which, as you say, is probably
orthogonal to the intermediate representation.


Cheers,
Jeremy
---
http://www.cs.man.ac.uk/~jsinger

Return to the comp.compilers page.
Search the comp.compilers archives again.