craig.topper added inline comments.
================ 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" ---------------- jrtc27 wrote: > craig.topper wrote: > > jrtc27 wrote: > > > 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. > > For each signature there is effectively a single key type that is a vector. > > The type transformer is a list of rules for how to derive all of the other > > operands from that one key type. Conceptually similar to > > LLVMScalarOrSameVectorWidth or LLVMHalfElementsVectorType in Intrinsics.td. > > Some types are fixed and don't vary by the key type. Like the size_t vl > > operand or a store intrinsic returning void. There is no separate place to > > put a base type. > Oh I see, I hadn't appreciated that TypeRange got split up and each character > was a whole separate intrinsic, I had misinterpreted it as it being a list of > the types of arguments, i.e. an N-character string for an (N-1)-argument > (plus return type) intrinsic that you could then use as a base and apply > transformations too (e.g. "if" for a float-to-int intrinsic, with "vv" etc > giving you a vectorised versions) and so was confused as to why the > void/size_t/ptrdiff_t/uint8_t/bool-ness couldn't just be pushed into the > TypeRange and the corresponding transforms left as "e". But, how _would_ you > define vector float-to-int (and back) conversions with this scheme then? > > On a related note, I feel one way to make this less obfuscated is change > v/w/q/o to be v1/v2/v4/v8 (maybe with the 1 being optional, don't really > care), and is also more extensible in future rather than ending up with yet > more alphabet soup, though it does change the parsing from being a list of > characters to a list of strings. I think these transforms are used for the float-to-int and int-to-float. // I: given a vector type, compute the vector type with integer type // elements of the same width // F: given a vector type, compute the vector type with floating-point type // elements of the same width The float and integer types for conversion are always the same size or one lmul up or one lmul down. So combining I and F with v or w should cover it. 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
