SFX instructions emission slow cases

As I understand there are two passes to translate SFX bytecode to the native code(functions privateCompileMainPass() and   privateCompileSlowCases()).
So whats the purpose of privateCompileSlowCases(). Why we need slow cases for each bytecodeInstruction? Is it needed when arguments of instruction not integer or something else?

JavaScript is a dynamically typed language. Therefore, we cannot know for sure what types of values may flow into an instruction at the time we compile it. a + b may be an integer addition that produces an integer result, an integer addition that overflows and produces a double, an addition of a double to an integer, an addition of an integer to a double, a double addition, a string concatenation, or an "object-to-value" conversion followed by any of the previous.

But the common case is typically going to be an integer addition or a double addition.

Therefore, the baseline JIT (which you seem to be looking at) has a fast path for the common cases and a slow path for the uncommon ones.  The slow path almost always results in a C function call, which then does all of the magic necessary to satisfy JS semantics.

Similar things happen for almost all other JS instructions: there is a simple path for the cases we have found to be common and a slow-path C function call for the rare cases.

The slow paths are emitted as a separate piece of out-of-line code because that optimizes instruction cache locality for the main path, and helps a bit with branch prediction.

However, if you want to see how JSC actually makes JavaScript run fast, you should probably also look at either the LLInt (which enables very fast start-up by using a well-tuned threaded OSR-capable interpreter) or the DFG (which enables high throughput for longer-running code by leveraging value profiling to avoid having to deal with JS's dynamism in most cases). The baseline JIT is still probably important for performance, but this is becoming less and less true as the LLInt is likely to get faster and the DFG is likely to expand coverage to more kinds of code (DFG still cannot compile some functions at all due to missing opcode support).