Re: Upvalue elimination in loops
- From: Mike Pall <mike-1311@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 24 Nov 2013 03:45:33 +0100
Szabó Antal wrote:
> Now there's a move that's copying back the current value of i into the
> upvalue, which I think is a dead store at all but the last iteration,
> thus LuaJIT could move it after the loop (well, in this example
> there's actually no "after the loop", but generally).
This would be a variant of store sinking.
> This *seems* easy, but I'm far from an expert in this area.
Far from it. Store sinking, as needed by allocation sinking, added
a lot of complexity. But it was worth it, because it allowed
sinking of (temporary) allocations, which are rather expensive.
Stores themselves are rather cheap, though. Most modern super-scalar
CPUs have a dedicated execution port for stores which is often
underused. A couple unnecessary stores rarely have any effect on
overall performance.
> So is this something that's just not implemented because nobody ever
> needed it, or is it too hard (impossible?) to do?
Sure, one could extend store sinking to deal with cases such as
the above. But those cases are rare, yet the expensive analysis
would have to be run for _all_ stores. This wouldn't be a good
trade-off for a JIT compiler.
[The analysis for allocation/store sinking is only triggered by
on-trace allocations. These occur less often than stores and the
ROI is much bigger.]
For anyone reading this out of context: LuaJIT already *does* sink
stores to locals (Lua stack slots). The analysis is a lot cheaper
since there's only trivial aliasing for stack slots. And the
implementation uses (sparse) stack snapshots, which is much
cheaper, too.
--Mike
Other related posts:
