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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits