instructions. Also add regression tests.
Add reason and idea.
I remember why I use I64 here. This instruction is vector integer add instruction. I didn't use F32 here since our F32 has represented only f32 values. It doesn't represent i32 values.
However, it may be possible to assign not only f32 but also i32 to F32 register class and use F32 here. Similarly, it is also possible to assign both f32 and i32 to I32 register class too since VE has vector floating-point add instruction like "PVFADDLO".
Let me consider this.
I like your idea of mapping f32/i32 to both I32 and F32. AFAIK, the mapping between types (eg i32) and registers (eg F32) only matters for isel pattern constraints (custom lowering code is not subject to those constraints).
Change my mind. Stop previous plan to change.
I like that idea too. But, I understand doing that needs a lot of work. Can we merge this one as is and try to optimize it later?
For example, it is possible to define f32 and i32 to both F32 and I32. However, it doesn't help ISel patterns at the moment. Let consider about implementing AND for higher i32 and lower i32. What kind of patterns we can to write? Pat<(i32 (and ... doesn't work. Maybe we can write Pat<(I32 (and... and Pat<(F32 (and.... I've not tried it yet. Then, we also need a lot of patterns to make it worth.
So, let me merge all vector instructions first.