On Thu, Nov 21, 2019 at 07:41:56PM +0000, Richard Sandiford wrote: > Nicholas Krause <xerofo...@gmail.com> writes: > >> + /* The instructions we're combining, in program order. */ > >> + insn_info_rec *sequence[MAX_COMBINE_INSNS]; > > Can't we can this a vec in order to grow to lengths and just loop through > > merging on instructions in the vec as required? > > Yeah, extending this to combining more than 2 instructions would be > future work. When that happens, this would likely end up becoming an > auto_vec<insn_info_rec *, MAX_COMBINE_INSNS>. I imagine there would > still be a fairly low compile-time limit on the number of combinations > though. E.g. current combine has a limit of 4, with even 4 being > restricted to certain high-value cases. I don't think I've ever > seen a case where 5 or more would help.
And sometimes it looks like 4 would help, but often this is because of a limitation elsewhere (like, it should have done a 2->2 before, for example). 4 _does_ help quite a bit with irregular instruction sets. It could sometimes help with RMW insns, too, but there are other problems with that. What you see a lot where 4 "helps" is where it really should combine with just 3 of them, but something prevents that, often cost, while throwing in a 4th insn tilts the balance just enough. We used to have a lot of that with 3-insn combinations as well, and probably still have some. Segher
