Re: [MIT-Scheme-devel] Y combinator RTL

[Taylor R Campbell]

Actually, it looks like might be related to frame overwriting rather
than closure analysis.  In particular, before RTL optimization, the
RTL generated for g ended like this:

;; Start overwriting frame by storing f in the operator position.  (*)
(assign (offset (register 4) (machine-constant 0)) (register #x10))

;; Cons closure for h.
(assign (register #x15) (cons-closure (entry:procedure lambda-1) 2 2 1))
(assign (register #x14) (cons-pointer (machine-constant #x28) (register #x15)))
(assign (register #x16) (object->address (register #x14)))

;; Copy 0(sp) into h.  But did the compiler think it would find f or g
;; at 0(sp)?  If the compiler thought it would find f, it's probably a
;; bug in closure analysis.  If the compiler thought it would find g,
;; it's probably a bug in frame overwriting.
(assign (register #x17) (offset (register 4) (machine-constant 0)))
(assign (offset (register #x16) (machine-constant 2)) (register #x17))

;; Finish overwriting frame by storing h in the first argument
;; position.  (**)
(assign (register #x13) (register #x14))
(assign (offset (register 4) (machine-constant 1)) (register #x13))
(invocation:apply 2 #f)

Persuading the RTL generator to move (*) forward to (**) would fix at
least this case of the problem.