On Sat, Oct 24, 2020 at 2:20 AM Eugene Rozenfeld via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > This patch adds a pattern for folding > x < (short) ((unsigned short)x + const) > to > x <= SHORT_MAX - const > (and similarly for other integral types) if const is not 0. > as described in PR97223. > > For example, without this patch the x86_64-pc-linux code generated for this > function > > bool f(char x) > { > return x < (char)(x + 12); > } > > is > > lea eax,[rdi+0xc] > cmp al,dil > setg al > ret > > With the patch the code is > > cmp dil,0x73 > setle al > ret > > Tested on x86_64-pc-linux.
+/* Similar to the previous pattern but with additional casts. */ +(for cmp (lt le ge gt) + out (gt gt le le) + (simplify + (cmp:c (convert@3 (plus@2 (convert@4 @0) INTEGER_CST@1)) @0) + (if (!TYPE_UNSIGNED (TREE_TYPE (@0)) + && types_match (TREE_TYPE (@0), TREE_TYPE (@3)) + && types_match (TREE_TYPE (@4), unsigned_type_for (TREE_TYPE (@0))) + && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@4)) + && wi::to_wide (@1) != 0 + && single_use (@2)) + (with { unsigned int prec = TYPE_PRECISION (TREE_TYPE (@0)); } + (out @0 { wide_int_to_tree (TREE_TYPE (@0), + wi::max_value (prec, SIGNED) + - wi::to_wide (@1)); }))))) I think it's reasonable but the comment can be made more precise. In particular I wonder why we require a signed comparison here while the previous pattern requires an unsigned comparison. It might be an artifact and the restriction instead only applies to the plus? Note that + && types_match (TREE_TYPE (@4), unsigned_type_for (TREE_TYPE (@0))) unsigned_type_for should be avoided since it's quite expensive. May I suggest && TYPE_UNSIGNED (TREE_TYPE (@4)) && tree_nop_conversion_p (TREE_TYPE (@4), TREE_TYPE (@0)) instead? I originally wondered if "but with additional casts" could be done in a single pattern via (convert? ...) uses but then I noticed the strange difference in the comparison signedness requirement ... Richard. > Eugene >