This is a catch all bug report to document failures in combine. There are at least two problems with combine. 1) It only combines chains of instructions that have no other uses of the intermediate results. 2) It functions by generating promising patterns and then seeing if they exist. This is wasteful, in that it generates many patterns that don't exist on the particular target, and it is blind in that it doesn't spot any special cases the target might have. Really combine, which is a generic peepholer, needs some kind of templatizing on the target machine. What's needed is something like pre-reg-alloc peepholes. That of course would be a large amount of work.
I think the way meta-bugs are done has been changed; should the bugs blocking this be moved to "Depends on" instead?
(In reply to Eric Gallager from comment #1) > I think the way meta-bugs are done has been changed; should the bugs > blocking this be moved to "Depends on" instead? I'm doing that.
1) Isn't true. But it is true that usually a SET is only tried together with its first USE (trying all USEs would be quite expensive, probably even noticably quadratic, and would not normally help. But maybe trying just the first and second USE helps?) 2) This is also a strength: combine can find all kinds of pattern that you never would think of. But I think an automated peepholer like you describe could be useful as a separate pass, one you could run more often, for example right after every splitter pass (on the insns that were split).
Does the new combine2 pass proposed for GCC 10 address any of these issues?