https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> --- Hi! (In reply to Jeffrey A. Law from comment #12) > Yea, if you've already exhausted what can be done via simplify-rtx, then > your best shot at avoiding the define_insn_and_split isn't going to work. simplify-rtx is *only* for cases where the RTL itself can be made simpler, it can be *more* expensive for a particular target even (to implement that RTL with some semi-directly translation to machine code)! simplify-rtx is essentially never a good place to optimise the generated machine code. > The simplify-rtx changes are still useful, obviously, but insufficient to > fix the problem on their own. > > As to whether or not combine should support 4->3 combinations. It would be > great to have that support. In my quest to reduce the RISC-V port's > reliance on define_insn_and_splits I've certainly stumbled over numerous > cases where 4->3 splits would be useful. 4->3 combinations already can be (indirectly) done. But it will never be done directly! The combine pass only ever combines 2, 4, or 4 insns into one. If that is not a recognised instruction, it tries to split that insn into multiple insns in a variety of ways. It can use a define_split (directly! It does not have to accept anything intermediate as a valid insn! This is the main use of define_split, even). But it also uses pretty stupid heuristics to split the SET_SRC into two parts. This isn't very effective, and extending this to three parts will have a success rste of less than a percent. Let's not try to go there. Do we have any example where we would want combine to generate three insns? > I don't think there's anything inherently blocking 4->3 combinations. It's > "just" a matter of adding the support in combine. I expect that will be > non-trivial from an implementation standpoint. combine already *can* do this, *does* do this, in cases. A generic thing that splits using heuristics will not do satisfyingly well.
