Hi Richard Thanks for the review.
> Can you show the former original GIMPLE and matched patterns and the > resulting optimized pattern sequence? After inlining, the relevant scalar GIMPLE presented to the vectorizer is: _117 = _116 + 16; _118 = _117 >> 5; x.2_165 = (unsigned int) _118; _403 = -x.2_165; _166 = (int) _403; _167 = _166 >> 31; _450 = x.2_165 > 255; _168 = _450 ? _167 : _118; iftmp.1_169 = (unsigned char) _168; *_119 = iftmp.1_169; The over-widening pattern determines that the shifted result can be computed in a signed short: patt_225 = patt_226 + 16; patt_224 = (signed short) patt_225; patt_222 = patt_224 >> 5; patt_221 = (int) patt_222; Without this patch, the SAT_TRUNC pattern consumes the promoted value: patt_221 = (int) patt_222; patt_max = MAX_EXPR <0, patt_221>; patt_out = .SAT_TRUNC (patt_max); This produces the following sequence on RISC-V: vsetvli zero,zero,e16,mf2,ta,ma vsra.vi v29,v28,5 vsetvli zero,zero,e32,m1,ta,ma vsext.vf2 v30,v29 vmax.vv v31,v30,v3 vsetvli zero,zero,e16,mf2,ta,ma vnclipu.wi v31,v31,0 vsetvli zero,zero,e8,mf4,ta,ma vnclipu.wi v31,v31,0 The resulting optimized sequence is: vsetvli zero,zero,e16,m1,ta,ma vsra.vi v30,v29,5 vmax.vv v31,v30,v12 vsetvli zero,zero,e8,mf2,ta,ma vnclipu.wi v31,v31,0 > Please do not build a GENERIC MAX_EXPR, instead use the appropriate > gimple_build_assign overload (this also suggests this was LLM generated). The current master implementation already constructs the MAX_EXPR through build2. My patch retained this form and only replaced ops[0] with input. However, I agree that this code should use the appropriate GIMPLE builder directly. > Also I fail to see a check that the generated MAX_EXPR is supported by > the target? I agree that the complete generated sequence should be validated. I will add a target-support check for MAX_EXPR in the candidate input type. Best regards, Wang Jue
