Don't introduce reinterprets in find/lower intrinsics

[rootjalex]

As discussed with @abadams , later lowering stages expect to see int/uint reinterprets to have been normalized to casts. This PR removes the places in find_intrinsics and lower_intrinsics that introduce reinterpret, and use cast instead.

[rootjalex]

Failures appear unrelated

[pranavb-ca]

Thank you for this @rootjalex. @prasmish- Isn't this essentially what we were talking about this morning? Can you please take a look if it helps your case?

[rootjalex]

@pranavb-ca No problem!

Btw, I have a PR that I am working on that is aiming to improve handling of reinterpret/casts that do reinterprets, for ARM and HVX codegen. If you / your team are working on something similar, it might be useful to coordinate. I've been running into a lot of headaches with HexagonOptimize for that PR.

[rootjalex]

An example:

x_i16 + widening_mul(y_u8, (int8)3)

On ARM, it's better to rewrite this to:

x_i16 + i16(widening_mul(y_u8, (uint8)3))

and target umlal. However, on HVX, this pattern maps to vmpybusv_acc, so we shouldn't lift to the reinterpreted widening_mul (although, for this particular example, vmpyubv_acc could be used for the operation as well). The general theme is this: on non-HVX architectures, it's almost always better to rewrite widening_mul(u, i) to reinterpret(widening_mul(u, u)) if possible (i.e. the signed operand is a positive constant), but this causes all sorts of issues with HVX codegen, which is generally better at handling mixed-signed widening_mul. I almost want to fix this by having find_intrinsics accept the Target and only apply certain rules if not targeting HVX

[pranavb-ca]

Thanks, @rootjalex.
@prasmish is working on this on our end. I have spoken to him and he'll keep you posted.