Changes

This desaturation loop is repeated 200 times. The first time the desaturation loop runs, the (R, G, B) values are converted from integers to doubles. The remaining 199 times, the values are doubles to begin with, and so the fragment always side-exits to a secondary fragment. Avoiding this (type inference?) would make a big difference, because (a) the GETELEM we abort on has to be repeated, and (b) the code in the secondary fragment is worse because CSE does less because it has less context to work with.

The trace code generated assumes the array elements are integers, because that's what is seen at record-time, but in the end 99.5% of the time it's not, so we end up taking a particular side-exit every time to a second trace fragment. This really hurts, because (a) the GETELEM we abort on has to be repeated, and (b) the code in the secondary fragment is worse because CSE does less because it has less context to work with. Some experiments show this costs us something like 10--20%.

If bug 603841 isn't fixed, it would be good if we could somehow (using the oracle?) detect that the side-exit is hot and recompile the fragment. Or, maybe type inference could identify that it's really an array-of-doubles and then we'd only side-exit 0.5% of the time. After that's fixed, better alias analysis of the slot stores in the SETELEMs would help CSE a lot. More specifically, if you have GETELEM followed by SETELEM and they both access the same element, the SETELEM can be optimized quite a bit. But here we have GETELEM(a), GETELEM(b), GETELEM(c), SETELEM(c), SETELEM(b), SETELEM(a) and the intervening SETELEMs prevent the latter two SETELEMs from being optimized in this way. But this would require a big extension of the current simple alias analysis, which would be difficult.