Previously, the snippet generators always emit a jump at the end of the fast path. In the baseline JIT and FTL, this results in a jump to the very next instruction. I've change it to assume that the fast path will just fall thru, and let the client decide instead if it wants/needs a jump or not after the fast path.
I also changed the generators to provide a didEmitFastPath() query explicitly declare if they actually generated the fast path, instead of having the client infer it from an empty endJumpList.
Created attachment 265791 [details]
Created attachment 265792 [details]
x86_64 benchmark result.
Comment on attachment 265791 [details]
Small tweaks to snippet code generation might be nice -- but as you can see from benchmark results, they don't influence the bottom line. It's much more valuable to move forward with more snippet coverage, since that will influence the bottom line.
Thanks for the review. For the record, this work came out of investigating some baseline perf regressions in the op_mul snippet work: https://bugs.webkit.org/show_bug.cgi?id=151393. I just updated op_add and op_sub here to match and ran the benchmarks for a sanity check.
Landed in r192599: <http://trac.webkit.org/r192599>.
This patch exposed a bug: https://bugs.webkit.org/show_bug.cgi?id=151445. The fix for that landed in r192632.