Multiple assignment has too much overhead

[headius]

Multiple assignment has taken a perf hit in 9k compared to 1.7, and there's other opportunities to go beyond 1.7.

The main issue is that it's always producing the RHS array for some forms, and simply not eliminating it for other forms.

This case should optimize to simple moves. I believe it doesn't because DCE is not running:

a, b, c = d, e, f

This case, where ary is already an array, should not have to dup the array. I believe we dup it now preemptively because it may be used as the return value of the expression. However this won't go away with DCE because ary is opaque (assume it's opaque below).

ary = [1,2,3]
...
a, b, c = *ary

These cases affect performance on e.g. https://github.com/YorickPeterse/oga because it uses masgn in the second way above. Many other libraries use these forms too.

[chrisseaton]

This would explain many of the regressions I'm seeing on my benchmark suite - a lot of them use masgn.

[headius]

1.7 could detect the first form but not the second form, but they're both pretty common.

[enebo]

I made a patch for this simple form a week or two ago and it did optimize well but at that point we(subbu) noticed LocalOptimizationPass was no longer executing at all. With LOP re-enabled it was able to eliminate the array. My optimization was very specific to Masgn and LOP was optimizing this generically. The neat thing about the patch is it reduced specialized instrs to a series of Copy(). The unneat thing is that patch + LOP decreased perf by 10x (don't know why).

I will try and get a clean patch for my change. I recently squashed masgn and masgn19 to one class so this is conflicting atm.