https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63577
--- Comment #18 from Segher Boessenkool <segher at gcc dot gnu.org> --- I wouldn't say there really _is_ an issue in combine; not an implementation issue, at least. Combine is designed to blindly try every combination it can try, without first seeing if that is likely to result in success. This is what gives it its power. (*) In the testcase a lot of combinations are possible for the one small group of patterns that is repeated many times. This is why it takes so much time (and then also produces a lot of garbage RTL). I put the blame for that on the huge input to combine though, which shouldn't be there in the first place. Combine is sort of linear, just with a huge constant. Nothing I've seen in here violates that. Things will improve if can abort a combination attempt earlier, if we can detect it cannot possibly result in a successful combination. Things are much complicated by the fact that e.g. sometimes a 2-insn combination fails, but then a 3-insn combination works while in effect it just does that 2-insn combination plus it leaves a single insn untouched: this happens because when it tries the 3-insn combo combine knows more about the register values. The whole reg_stat thing needs a big overhaul. (*) This is weakened somewhat for four-insn combinations, those just would take way too long.
