TODO

[src/ext/cpc.ml]
* during CPS conversion, if there is a typo in a cpc_spawn, building
  fails with a Not_found error message
  => print a more informative error message (or check it before)
* OPT: There is an inefficiency with return values:
  x = f(); return x; is converted to
  x = f(); w(x); return; with w(x){return x;}
  This is by design in CPC but I think we can't avoid it anyway since
  CIL (sometimes) produces the following in the first place:
  tmp = f(); x = tmp;
  (Yes, even when there is NO cast implied.)
  In that case, w becomes: w(tmp){x = tmp; return x;}
  Both cases could probably be optimized just before cps conversion,
  basically by removing w (this would save a function call, and a patch,
  f patching directly the next continuation, instead of going through 
  w).
* OPT: Return probably does not have to be split if there is no
  assignment before it
  => is it worth the trouble?
* cpc_yield in detached mode should reattach to the threadpool (if it is
  saturated), or be a no-op otherwise.
* loop optimisation:
  f(i,j,k) { i++; g(k,i,j);} => g(k, i++, j);
  => does not occurr in real-world code (Hekate)
* what should we do with attributes, const, restrict, volatile, etc.?
  => they are copied (are they?) in the struct definition.  Does that
  make any sense?
* order parameters in functions resulting from goto elimination (except the
  last one) to minize padding.

[src/frontc/cabs2cil.ml]
* if an inner cps function uses a free variable which has not been declared
  yet, conversion fails with "Cannot resolve variable i."

[runtime representation]
* is there a way to avoid wasting space on x86-64?
  => it's all about doubles (which are 16-bit aligned).
  => more generally, reordering function parameters in (generated) cps
  functions would be a good idea.