ZJIT: Split InvokeBlock into GetBlockHandler/GuardBitEquals/SendWithoutBlock

[tekknolagi]

This way we can re-use a lot of our specialization machinery.

[XrXr]

Blocks have different parameter setup features than methods, so SendWithoutBlock needs to take on an extended feature set for this, or we need to split SendWithoutBlock into parameter setup and frame push so the parameter setup part could be substituted as fit.

[tekknolagi]

What would your proposed split look like? I like splitting opcodes

[XrXr]

Just a rough draft:

1. BlockHandler <takes the &block_arg object>, this makes the bloc.to_proc call visible in HIR as another send. But it's tricky, because once we call to_proc from JIT code, side exiting to the start of the interpreter send would end up calling to_proc twice. Extra care required.
2. CallWithFrame arg1, arg2, ..., spec_val, cme sets up callee's locals and control frame. For methods, spec_val is the block handler, for blocks, it's the block's environment, computed beforehand either way. The number of passed args must match the callee's parameter at this point. Fancy argument-parameter negotiations happen before this opcode. This is flexible enough to handle sends and yields and supers.

We'd only split into these for sends with a speculated callee and keep the interpreter-analogous fallback opcodes.

[tekknolagi]

Ok, now we have re-organizing of parameters thanks to Randy's work for keywords. Is that enough to do the block parameter setup, @XrXr? Or what more do we need?

[XrXr]

It can be made to work now, for sure, but it feels messy. SendDirect has a cme field, so it's first and foremost designed for calling into methods. The control frame for a running block is different from that of a method, but it's possible to fix that by expanding what SendDirect does.

I think we want a CallWithFrame type of deal, for this and for #918.