Re: [ANN] LuaJIT Roadmap 2012/2013
- From: Mike Pall <mike-1206@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 13 Jun 2012 14:40:17 +0200
Robert G. Jakabosky wrote:
> What I am trying to get at is that only if the value is stored where the GC
> can find it should the store be counted as an escape. If the value is only
> stored in another cdata or passed to an C function it shouldn't be counted as
> an escape, since the GC will not see it and will collect it.
This is a correct analysis, but for a different problem.
Allocation sinking doesn't work that way. The used escape analysis
checks for escaping pointers, not escaping values. Together with
store-to-load forwarding, only the allocation and the related
stores remain. If the stores can be sunk, so can the allocation,
provided there are no escaping pointers. In SSA terms: there's no
other 'use' for the allocation return value.
This has the same effect as SRA (scalar replacement of aggregates),
except it's much simpler and works in more contexts. Fields of
aggregates are replaced by SSA values, which are turned into
registers and/or spill slots later on. Ok, so those spill slots
(if any) are on the stack -- but they do not match the layout of
the original struct/array/table _at all_.
Allocation sinking _eliminates_ the allocation. It does not
_transform_ the heap allocation into a stack allocation. That's a
very different problem.
Sure, I might add that optimization in the future. But: a) it won't
work on regular table objects and b) it's an extension and not a
replacement for allocation sinking. Stack allocation alone is less
efficient. You still need SRA to move all computations to registers
and then (maybe) eliminate the allocation.
--Mike
Other related posts:
