[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.


================
Comment at: clang/include/clang/Basic/riscv_vector.td:56
+//
+//   e: type of "t" as is (identity)
+//   v: computes a vector type whose element type is "t" for the current LMUL
----------------
khchen wrote:
> jrtc27 wrote:
> > Do we really need to invent an esoteric DSL?
> I think this is different design choose.
> Current design is based on https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi/-/blob/EPI/clang/include/clang/Basic/epi_builtins.td, personally I think it makes td file more simpler.
> 
> Of course we can make td file more complex little bit and list all legal type and combination like https://github.com/isrc-cas/rvv-llvm/blob/rvv-iscas/clang/include/clang/Basic/riscv_vector.td did.
> 
> In fact, I don't have a strong opinion on which one is better
> 
> ps. current approach is similar to arm_sve.td design, maybe they know the some critical reason.
I just find it really obfuscates things when we have all these magic character sequences.


================
Comment at: clang/include/clang/Basic/riscv_vector.td:66
+//      element type which is bool
+//   0: void type, ignores "t"
+//   z: size_t, ignores "t"
----------------
khchen wrote:
> jrtc27 wrote:
> > Then why aren't these just base types? We don't have to follow the brain-dead nature of printf.
> Basically builtin interface is instantiated by the "base type + LMUL" with type transformers. But in some intrinsic function we need a specific type regardless "base type + LMUL"
> ex. `vuint32m2_t vssrl_vx_u32m2_vl (vuint32m2_t op1, uint8_t op2, size_t vl);`
Then fix the way you define these? This is just bad design IMO.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95016