On 8/21/19 7:57 AM, Wilco Dijkstra wrote: > 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. I believe the expanders have access to more than one statement via the use-def chains and TER's transformations.
jeff
