Thanks Richard Biener, will have a try and keep you posted. Pan
-----Original Message----- From: Richard Biener <richard.guent...@gmail.com> Sent: Tuesday, October 17, 2023 4:23 PM To: Li, Pan2 <pan2...@intel.com> Cc: gcc@gcc.gnu.org; richard.sandif...@arm.com; juzhe.zh...@rivai.ai; kito.ch...@gmail.com Subject: Re: Vectorizer for types with different size On Mon, Oct 16, 2023 at 4:05 PM Li, Pan2 <pan2...@intel.com> wrote: > > Hi Richard Biener, > > Recently I am try to enable the RISC-V auto-vec for the lrint family, which > is trying to convert the HF/SF/DF to long type. > > Then I found the vectorizer can only act on the types with the same data > size. For example, DF to DI (long in RV64) works > well for standard pattern name lrintmn2 but fails on other combinations like > SF to DI. > > However, according the legacy hook > TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION may help to resolve the problem > but I would like to learn if there is any plan that the middle-end would like > to support the types with different size before we > start to implement the hook. I don't think using TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION would help here? It should be somewhat straightforward to support different vector size when nunits_in == nunits_out, so you could try just removing the restriction for that case in vectorizable_call. It's probably that the pre-selection of vector types will make it so that this easy special case isn't ever chosen though (I get WIDEN, but also a matched vector size on x86). The vectorizable_internal_function selection then doesn't actually check how the chosen vector types could be "split" - for both WIDEN and NARROW we'd have to check the associated vector types with the same number of lanes (obviously), and either the input split or the output composed then. Richard. > > I also have a try for ARM for this, you can reference this link > https://godbolt.org/z/o41hr9rY9. > > Thanks in advance and have a great day, ;)! > > Pan
