wangpc-pp wrote: > > Ping. > > And some updates on vector support: currently, `ExpandMemCmp` will only > > generate integer types (`i128`, `i256` and so on). So, if we simply add > > `128`, `256`, `vlen` to `LoadSizes`, the LLVM IR will use `i128`/`i256`/... > > and then they are expanded to legal scalar types as we don't mark > > `i128`/`i256`/... as legal when RVV exists. > > There are two ways to fix this: > > > > 1. Make `ExpandMemCmp` generate vector types/operations. > > 2. Make `i128`/`i256`/... legal on RISC-V. > > > > I think the first one is the right approach but I need some agreements on > > this. > > I think X86 only supports `IsZeroCmp` for vector and has a pre-type > legalization DAG combine to recognize the wide integer type. See > X86ISelLowering `combineVectorSizedSetCCEquality`.
Thanks! I didn't notice that, I will try to implement this similarly in RISC-V. > > General memcmp is complicated with vector. You need to find the first element > where the mismatch occurred and then compare only that element to find > whether it is larger or smaller. I don't know if you can write that in target > independent IR without it being really nasty and it wouldn't generate > efficient code. Yes, I have noticed it. I was thinking that if we generate vector code earlier, we may get more spaces for optimizations. I will still try this approach, but I won't hold out high hopes. https://github.com/llvm/llvm-project/pull/107548 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
