Hi Richard, > > > > I think this should be in expand stage where there could be comparison > > of the cost of the RTLs. > > I tend to agree here, if not then for the reason the "simplified" variants > have more GIMPLE stmts which means they are not "simpler". In > fact I'd argue for canonicalization we'd want to have the reverse > "simplifications" on GIMPLE and expansion based on target cost. So how would this work? Expand works on one statement at a time, but we are dealing with more complex expressions here. When we get a popcount (x) > 1 in expand_gimple_cond, the popcount has already been expanded. And the code in builtins.c that emits popcount doesn't see or consider the comparison, so it would be difficult to change it at that point. None of the infrastructure in expand seems to be set up to do complex pattern matches and replacements at expand time...
Costing would be difficult too since rtx_cost doesn't support builtins or calls, so each backend would need to be modified to add costs for these. So what is the best place to do pattern matches? I thought it was all moving to match.pd. Wilco
