Example: How a side trace inherits from a parent trace about raptorjit

[fsfod]

Snapshot creation is lazy based on the last IR instruction with side effects between guard instructions so most the time you will end up duplicating some stuff in a side trace. For the sample based Lua line IR profile markers a snapshot is always created for each one I think.

If you have too many live values going across to a side trace you can endup with the the dreaded NYI register coalescing too complex abort and the trying to JIT the uncompiled trace exit to to interpreter will fail with the same error most the time.

[lukego]

@fsfod The duplicate work should only be for instructions after the last snapshot though, right? I am surprised that the side trace took exit 2 but is repeating work that the parent did in snapshot 0. This seems redundant, no?

(Or maybe that work is being repeated for a different reason e.g. the TBAR invalidates the earlier guard results?)

[lukego]

@fsfod I tested removing the global = 0 line from the parent. Then there is no TBAR barrier but the child is still repeating all of the same instructions to locate the hashtable slot.

Just on a first casual inspection of the code it looks like side traces inherit values from the parent snapshot via lj_snap_replay() but nothing more? So guards and constant hashtable slot lookups etc will be repeated? (Opportunity for more aggressive de-duplication like LOOP opt?)