[PATCH] D89183: [VE] Add vector load/store instructions

[Kazushi Marukawa via Phabricator via llvm-commits]

kaz7 added inline comments.


================
Comment at: llvm/lib/Target/VE/VEISelLowering.cpp:637-672
+  addRegisterClass(MVT::v2i32, &VE::V64RegClass);
+  addRegisterClass(MVT::v4i32, &VE::V64RegClass);
+  addRegisterClass(MVT::v8i32, &VE::V64RegClass);
+  addRegisterClass(MVT::v16i32, &VE::V64RegClass);
+  addRegisterClass(MVT::v32i32, &VE::V64RegClass);
+  addRegisterClass(MVT::v64i32, &VE::V64RegClass);
+  addRegisterClass(MVT::v128i32, &VE::V64RegClass);
----------------
simoll wrote:
> kaz7 wrote:
> > simoll wrote:
> > > I wonder why there are vector types that do not map directly to vector registers.
> > Which types are not mapped as you are asked?  I think all vector types from v2f64 to v256f64 are mapped.
> Yes, they are mapped now, but why are there more vector types being added than necessary? For example, `v16f64` is not a vector register type for VE. If it was not mapped, LLVM could still legalize/expand it into a legal v256f64 type. 
> I was expecting to see only `v256i64`, `v256f64`, `v512i32`,`v512f32`,`v256i1` and `v512i1` in this list but there may be a good reason to have all other vector types here too.
I've understood your point.  The reason doing this is to support regular SIMD fixed-sized-vector optimization on VE in the future.  I would like to support both existing SIMD optimization and vector predication optimization.  This SIMD optimization for VE is partially implemented locally.

On the other hand, there was a discussion like that we should support not only V64 (16384) register but also V16384, V8192, V4096, ..., V64 registers.  Nobody except me wants it, so not implemented yet, though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89183/new/

https://reviews.llvm.org/D89183