https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #7 from Edwin Lu <ewlu at rivosinc dot com> --- Progress update: After discussing with Vineet and Robin, the optab for generating vnclipu does exist through IFN_SAT_TRUNC, which can be seen in a couple of the saturating arithmetic testcases Pan has been working on. The current patterns do support matching on gimple min/max truncates _3 = in_12(D) + _2; _4 = *_3; _5 = MIN_EXPR <_4, 255>; iftmp.0_8 = (uint8_t) _5; _6 = out_13(D) + _1; *_6 = iftmp.0_8; https://godbolt.org/z/q7j1T9bxf I'm currently working through adding a pattern in match.pd to recognize the sequence x264 generates and am encountering a problem in the generated gimple-match-4.cc. > _4 = *_3; > x.0_12 = (unsigned int) _4; > _38 = -x.0_12; > _15 = (int) _38; > _16 = _15 >> 31; > _29 = x.0_12 > 255; > _17 = _29 ? _16 : _4; > _18 = (unsigned char) _17; Right now, I'm doing (match (unsigned_integer_sat_trunc @0) /* SAT_U_TRUNC = X & (NT)(-1) ? (-X) >> 31 : X The gimple representation uses X > (NT)(-1) instead of using & so match on gt instead of bit_and. */ (cond^ (gt @0 INTEGER_CST@1) (rshift:s (convert? (negate @0)) INTEGER_CST@2) @0) which tries to check if the statement `_4 = *_3;` and `x.0_12 = (unsigned int) _4;` are equivalent when trying to evaluate the else statement.
