Re: Upvalue elimination in loops
- From: Szabó Antal <szabo.antal.92@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 25 Nov 2013 23:15:04 +0100
Thanks for the explanation!
2013/11/24 Mike Pall <mike-1311@xxxxxxxxxx>:
> 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:
