https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 31 May 2019, ffengqi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 > > --- Comment #20 from Qi Feng <ffengqi at gcc dot gnu.org> --- > I have tried to merge signed and unsigned together: > > /* x > y && x != ( 0 or XXX_MIN ) --> x > y */ > (for and (truth_and bit_and) > (simplify > (and:c (gt:c@3 @0 @1) (ne @0 INTEGER_CST@2)) > (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1))) > (if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1)) > && integer_zerop (@2)) > || (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1)) > && wi::eq_p (wi::to_wide (@2), > wi::min_value (TYPE_PRECISION (TREE_TYPE (@2)), > SIGNED)))) > @3)))) > > /* x > y || x != ( 0 or XXX_MIN ) --> x != ( 0 or XXX_MIN ) */ > (for or (truth_or bit_ior) > (simplify > (or:c (gt:c @0 @1) (ne@3 @0 INTEGER_CST@2)) > (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1))) > (if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1)) > && integer_zerop (@2)) > || (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1)) > && wi::eq_p (wi::to_wide (@2), > wi::min_value (TYPE_PRECISION (TREE_TYPE (@2)), > SIGNED)))) > @3)))) > > /* x < y && x != ( UXXX_MAX or XXX_MAX ) --> x < y */ > (for and (truth_and bit_and) > (simplify > (and:c (lt:c@3 @0 @1) (ne @0 INTEGER_CST@2)) > (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1))) > (if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1)) > && wi::eq_p (wi::to_wide (@2), > wi::max_value (TYPE_PRECISION (TREE_TYPE (@2)), > UNSIGNED))) > || (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1)) > && wi::eq_p (wi::to_wide (@2), > wi::max_value (TYPE_PRECISION (TREE_TYPE (@2)), > SIGNED)))) > @3)))) > > (That's not all of them, for that would be too long and I think it's not > necessary.) > > I also tried it on a x86 laptop, seems it does work. But I got a bootstrap > issue. I don't know if it's caused by my patch or the version of gcc I used to > compile. You can always try to bootstrap the same revision without your patch. > Another problem is that I can't craft some c/c++ code to test truth_and. Maybe > it's used by other languages? Is it necessary to use truth_and along side > bit_and? The C family will end up with truth_andif. > I have to make this work on a ppc64le machine, could you give me some hints of > where to look into? Upthread I mentioned LOGICAL_OP_NON_SHORT_CIRCUIT. For the testsuite we have --param logical-op-non-short-circuit=1 which you could put into dg-options. Upthread I said that the ifcombine workers should probably be rewritten to support the patterns from match.pd. An initial patch doesn't have to solve everything ;)
