On 04/05/21 09:44 +0200, Jakub Jelinek wrote:
Hi!genericize_spaceship genericizes i <=> j to approximately ({ int c; if (i == j) c = 0; else if (i < j) c = -1; else c = 1; c; }) for strong ordering and ({ int c; if (i == j) c = 0; else if (i < j) c = -1; else if (i > j) c = 1; else c = 2; c; }) for partial ordering. The C++ standard supports then == or != comparisons of that against strong/partial ordering enums, or </<=/==/!=/>/>= comparisons of <=> result against literal 0. In some cases we already optimize that but in many cases we keep performing all the 2 or 3 comparisons, compute the spaceship value and then compare that. The following patch recognizes those patterns if the <=> operands are integral types or floating point (the latter only for -ffast-math) and optimizes it to the single comparison that is needed (plus adds debug stmts if needed for the spaceship result). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? There are two things I'd like to address in a follow-up: 1) if (HONOR_NANS (TREE_TYPE (lhs1)) || HONOR_SIGNED_ZEROS (TREE_TYPE (lhs1))) is what I've copied from elsewhere in phiopt, but thinking about it, alll we care is probably only HONOR_NANS, the matched pattern starts with == or != comparison and branches to the PHI bb with -1/0/1/2 result if it is equal, which should be the case for signed zero differences. 2) the pr94589-2.C testcase should be matching just 12 times each, but runs into operator>=(strong_ordering, unspecified) being defined as
Should this say s/strong/partial/ ?
