Failing to reassociate arithmetic causes out-of-bounds access

[davidchisnall]

This line:

                doublebasemul(r->coeffs + ctr - 4, b->coeffs + ctr - 4, ax, (ctr - 4) / 4, add);

Adds a counter to the pointer and then subtracts four. The array is quite small (four bytes) and so ctr takes it out of representable bounds and -4 brings it back in. If this were lowered as addi and then cincaddr, it would always be fine (and this should be sound: if the result is in representable bounds then this is fine, if the result isn't in the representable bounds then it doesn't matter that the intermediate bits are).

[resistor]

I don't think the diagnosis is completely accurate. The array is much larger than 4 bytes, as coeffs is an array of 256 int16_t's. But more importantly, because the indexing is happening inside a loop, the -4 offset actually gets hoisted out of the loop and applied up front, which is probably when the tag gets cleared. I can look into whether we can disable LICM for this scenario, but it will regress both code size and and dynamic instruction count.

[resistor]

To elaborate on that a bit, I don't think trying to reassociate this prior to ISel is likely to work out, as it seems that the optimizer prefers to canonicalize things the other way. However, in order for it even to be possible to custom select this in ISel, we need to get it there without getting LICM'd first.

[resistor]

#288