Open sh1boot opened 6 months ago
@llvm/issue-subscribers-backend-risc-v
Author: SH (sh1boot)
This may be related to https://github.com/llvm/llvm-project/issues/80392.
This seems to introduce risks of conflict with #80099 if two operands turn out to be immediate 0 with different sizes -- though I cannot think of an instruction which is still worth issuing at that point, so hopefully any bugs introduced with this optimisation will evaporate before the instruction is emitted.
Some microarchitectures may store different EEWs in a different internal format and may have a penalty for reading them with a different EEW than they were written with.
Yeah, I figured it could be like that (at least with floating-point it makes some sense). I'm not sure if the register pressure implied here could ever get to the point of justifying the complexity of switching this sort of thing on and off depending on whether or not it works for the given target.
Conversely, it does imply that my vreinterpret
workaround is actually non-zero-cost for those targets. Do they need a separate optimisation to fix that for them?
If you need two vectors of zeroes with different types, you might write something like:
Or you might write the equivalent expressions inline in other code. Either way this results in separate temporaries -- a wasted register and an unnecessary
vsetvli
/vmv.vx
pair.You can work around it with this:
It'd be helpful to fold these together if possible. I'm not sure what all the constraints are.