https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110461
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #4) > Yes it is that pattern, specifically : > /* Try to fold (type) X op CST -> (type) (X op ((type-x) CST)) > when profitable. > For bitwise binary operations apply operand conversions to the > binary operation result instead of to the operands. This allows > to combine successive conversions and bitwise binary operations. > We combine the above two cases by using a conditional convert. */ > (for bitop (bit_and bit_ior bit_xor) > (simplify > (bitop (convert@2 @0) (convert?@3 @1)) > (if (((TREE_CODE (@1) == INTEGER_CST > && INTEGRAL_TYPE_P (TREE_TYPE (@0)) > && (int_fits_type_p (@1, TREE_TYPE (@0)) > || tree_nop_conversion_p (TREE_TYPE (@0), type))) > || types_match (@0, @1)) > && !POINTER_TYPE_P (TREE_TYPE (@0)) > && TREE_CODE (TREE_TYPE (@0)) != OFFSET_TYPE > /* ??? This transform conflicts with fold-const.cc doing > Convert (T)(x & c) into (T)x & (T)c, if c is an integer > constants (if x has signed type, the sign bit cannot be set > in c). This folds extension into the BIT_AND_EXPR. > Restrict it to GIMPLE to avoid endless recursions. */ > && (bitop != BIT_AND_EXPR || GIMPLE) > && (/* That's a good idea if the conversion widens the operand, thus > after hoisting the conversion the operation will be narrower. > It is also a good if the conversion is a nop as moves the > conversion to one side; allowing for combining of the > conversions. */ > TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type) > /* The conversion check for being a nop can only be done at the > gimple > level as fold_binary has some re-association code which can > conflict > with this if there is a "constant" which is not a full > INTEGER_CST. */ > || (GIMPLE && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION > (type)) > > Those 2 above TYPE_PRECISION . For vectors this also lacks a check the resulting bit operation is supported. I'm testing a patch.
