Oh, gotcha. Yeah we would not be able to optimize C code. Maybe one day it will motivate a pure Ruby impl but today is not that day.tekknolagi (Maxwell Bernstein)
I am hopeful that in the medium-long term, ZJIT will be able to "see through" and even elide general Ruby object allocations when possible. We have some more cleanup and feature work before that becomes possible (for example, a function ...tekknolagi (Maxwell Bernstein)
Implements codegen for `ArrayMax` (opt_newarray_max) by calling the `rb_vm_opt_newarray_max` VM helper, following the same pattern as `ArrayHash` and `ArrayInclude`.tekknolagi (Maxwell Bernstein)
* Use sparse sorted Vec for IseqProfile instead of dense pre-allocated Vecs Replace the two dense Vec fields (opnd_types and num_profiles) that were pre-allocated to iseq_size for every ISEQ with a single sorted Vec<(u32, ProfileEntry)>...tekknolagi (Maxwell Bernstein)
* ZJIT: Only emit IncrCounter instructions in stats mode This cleans up a lot of HIR output when we're not explicitly measuring counters. They don't generate code when not in stats mode so they are just HIR clutter. * ZJIT: Enable stat...tekknolagi (Maxwell Bernstein)
- Add `for_each_operand`, `for_each_operand_mut`, and `try_for_each_operand` methods to `Insn`, backed by a shared `for_each_operand_impl!` macro - Replace the old `worklist_traverse_single_insn` function on `Function` with direct use of...tekknolagi (Maxwell Bernstein)