Rewrite slot allocation pass
authorAndy Wingo <wingo@pobox.com>
Fri, 15 Nov 2013 10:17:18 +0000 (11:17 +0100)
committerAndy Wingo <wingo@pobox.com>
Fri, 15 Nov 2013 10:17:18 +0000 (11:17 +0100)
commit987c1f5ff333dfa57e1e08b472d79f194e40ad0b
tree93c518711d7e544bb1545b38818a5a710e6ec307
parent13085a828f6d31c6aaf1e0c403dbe4d1b9dd1449
Rewrite slot allocation pass

* module/language/cps/slot-allocation.scm ($allocation): Refactor
  internal format of allocations.  Instead of an allocation being a hash
  table of small $allocation objects, it is an $allocation object that
  contains packed vectors.
  (find-first-trailing-zero): Rework to not need a maximum.
  (lookup-maybe-slot): New interface.
  (lookup-slot): Raise an error if a var has no slot.
  (lookup-call-allocation): New helper.
  (lookup-constant-value, lookup-maybe-constant-value):
  (lookup-call-proc-slot, lookup-parallel-moves): Adapt to $allocation
  change

  (allocate-slots): Rewrite so that instead of being recursive, it
  traverses the blocks in CFA order.  Also, procedure call frames are
  now allocated with respect to the live set after using arguments (and
  killing any dead-after-use vars); this should make call frames more
  compact but it does necessitate a parallel move solution.  Therefore
  parallel moves are recorded for all calls, for arguments; also if the
  continuation is a $ktrunc, the continuation gets parallel moves for
  the results.

  This rewrite is in preparation to allocating call args directly in the
  appropriate slots, where possible.

* module/language/cps/compile-rtl.scm (compile-fun): Adapt to slot
  allocation changes, using lookup-maybe-slot where appropriate,
  performing parallel moves when calling functions, and expecting return
  moves to be associated with $ktrunc continuations.
module/language/cps/compile-rtl.scm
module/language/cps/slot-allocation.scm