diff options
author | Jeremy Evans <[email protected]> | 2024-01-26 14:01:55 -0800 |
---|---|---|
committer | Jeremy Evans <[email protected]> | 2024-01-27 14:47:07 -0800 |
commit | 8a027d111fb5adf87dddd890e846c4814539d866 (patch) | |
tree | 1212141657bbab08064fdbbe1456636753799afe /compile.c | |
parent | d917bb8e60c283981626876c496cb2670f74ffb7 (diff) |
Remove expandarray/splatarray sequence peephole optimization
newarray, duparray, concatarray, and splatarray always leave an
array at the top of the stack. expandarray does not, it takes
an array from the top of the stack as input, and leaves individual
elements on the stack. I assume no Ruby code generates the
expandarray/splatarray sequence, or it could break. The only
use of expandarray outside the peephole optimizer is in the
masgn code, and it does not appear to generate splatarray
directly after expandarray.
The splatarray/splatarray peephole optimization is probably
also wrong in the following case:
```
putobject [1,2]
splatarray false
splatarray true
```
This instruction sequence should result in a duplicate of
[1,2] at the top of the stack, but the peephole optimizer would
remove the `splatarray true`, resulting in change that made
[1,2] on top of the stack. I'm not sure Ruby code can generate
`splatarray false` followed by `splatarray true` (I could get it
to generate chains of `splatarray true`), so maybe this has no
effect.
newarray, duparray, and concatarray all result in newly allocated
arrays at the top of the stack, so they shouldn't have an issue
with removing either `splatarray true` or `splatarray false`.
Diffstat (limited to 'compile.c')
-rw-r--r-- | compile.c | 1 |
1 files changed, 0 insertions, 1 deletions
@@ -3582,7 +3582,6 @@ iseq_peephole_optimize(rb_iseq_t *iseq, LINK_ELEMENT *list, const int do_tailcal if (IS_INSN_ID(iobj, newarray) || IS_INSN_ID(iobj, duparray) || - IS_INSN_ID(iobj, expandarray) || IS_INSN_ID(iobj, concatarray) || IS_INSN_ID(iobj, splatarray) || 0) { |