Feature #18825
closedSpecialized instruction for "array literal + `.hash`"
Description
Feature #18611 is merged. That feature encourages people to write hash methods like this:
def hash
[@a, @b, @c].hash
end
I would like to add a specialized instruction for this case opt_newarray_hash
. It's similar to opt_newarray_max
and opt_newarray_min
but for the hash method.
ISeqs before the optimization:
== disasm: #<ISeq:hash@test.rb:1 (1,0)-(3,3)> (catch: FALSE)
0000 getinstancevariable :@a, <is:0> ( 2)[LiCa]
0003 getinstancevariable :@b, <is:1>
0006 getinstancevariable :@c, <is:2>
0009 newarray 3
0011 opt_send_without_block <callinfo!mid:hash, argc:0, ARGS_SIMPLE>, <callcache>
0014 leave
ISeqs after the optimization:
== disasm: #<ISeq:hash@test.rb:1 (1,0)-(3,3)> (catch: FALSE)
0000 getinstancevariable :@a, <is:0> ( 2)[LiCa]
0003 getinstancevariable :@b, <is:1>
0006 getinstancevariable :@c, <is:2>
0009 opt_newarray_hash 3
0011 leave
The new instruction allows us to avoid allocating a new array and also avoid pushing a stack frame.
The implementation is here, and I've also attached a patch.
Files
Updated by mame (Yusuke Endoh) over 2 years ago
Just an idea. Is it possible to introduce a general instruction like opt_newarray_send
instead of individual opt_newarray_*
instructions?
Updated by tenderlovemaking (Aaron Patterson) over 2 years ago
mame (Yusuke Endoh) wrote in #note-1:
Just an idea. Is it possible to introduce a general instruction like
opt_newarray_send
instead of individualopt_newarray_*
instructions?
It should be possible (IMO). But I guess it means the bytecode might be larger for opt_newarray_min
and opt_newarray_max
because we probably need to add a parameter for opt_newarray_send
. Maybe it's not a big deal though. I will try making a patch.
Updated by tenderlovemaking (Aaron Patterson) over 1 year ago
- Status changed from Open to Rejected
Closing in favor of #18897