When both the source and target types have the same width, avoid resizing. This gets rid of up to 2 extra instructions when converting to a saturation type.
This doesn't seem to address the particular case in the integer conversion patch. In fact, I don't see those conversions at all.
|382 ↗||(On Diff #184641)|
Hm, there's a weakness with this emission. This is no longer a min-max pattern, which means it will be a lot harder to generate code for.
I was initially planning on rebasing and updating the parent patch of this after you took a look at it, but I did not account for the min-max pattern. Incidentally, we can still get the same results without having to change a lot of other tests or existing code if we just add a check for if the source and target have the same width. The saturation test cases these affect are the same as in the previous revision without having to change the other operations and still uses the min-max pattern.
In regards to solving the problem of resizing for int conversions, I'm starting to think that we will need that initial resize since if we want to retain the min-max pattern for all conversions, then it would be necessary to extend and shift when converting from an int to fixed point. Otherwise, I think we'd have the initial pattern I proposed where we check against the source value, but not have this pattern.
Yes, I'm starting to think so too. It's just not possible to not resize and keep the minmax pattern at the same time. We can't upshift without resizing first (because any bits above the scale can affect saturation), and if we wanted to saturate purely on the non-rescaled value, then the (mandatory) rescaling after saturation could destroy the possibly saturated result (since it would shift in zeroes from the right if upscaling, which breaks the result if it saturated to max).
Sorry for going down this path, that was rather pointless.
This seems off. We're upshifting, then saturating on the upshifted value. But the top bits could have been shifted out, so the result might not be correct.
We can't upshift before saturating if the upshift could shift out bits.
If the upshift is moved after the saturation, then the saturation no longer works since it would be upshifting zeros into the saturation result, which is also wrong.
This is wrong for the same reason; it shifts out the sign bit so the comparison could be different.