> Combine is asking simplify-rtx.c to truncate an addition to QImode > and simplify-rtx.c is providing a reasonable representation of that. > It's the representation we should use when matching against .md patterns, > for example. The problem is that combine doesn't want to keep the > truncation in this case, but doesn't know that yet.
I disagree, I don't find it reasonable to turn an addition in SImode into an addition in QImode when the machine supports the former but not the latter. I agree that it may help in some contexts, but then the transformation should be restricted to these contexts. > Right, but the only complaint I know of is about its effect on combine. > And my point is that that complaint isn't about combine failing to combine > instructions per se. It's that combine is failing to remove a redundant > operation. With the right input, the same rtl sequence could conceivably > be generated on a CISC target like x86_64, since it defines all the required > patterns (SImode addition, QI->SI zero extension, SImode comparison). It > could also occur with a sequence that starts out as a QImode addition. So > trying to make the simplification depend on CISCness seems like papering > over the problem. The problem is that this changes the combinations tried by the combiner in a way that is adverse to most RISC targets. Sure, we could change all the affected back-ends but what's the point exactly? What do we gain here? Look for example at comment #4 in PR rtl-optimization/58295. > If you think the patch was wrong or if you feel the fallout is too great > then please feel free to revert it. I think that the fallout is too great for RISC targets, yes, so I'm trying to find a reasonable compromise. -- Eric Botcazou
