https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
Kishan Parmar <kishan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #14 from Kishan Parmar <kishan at gcc dot gnu.org> ---
Hi @Segher,
(In reply to Segher Boessenkool from comment #13)
> 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.
>
In above example, we already reach a clean 3-operation form (lshiftrt + and +
plus).
This is exactly a case where a 4→3 outcome would be useful. We are not trying
to split some complex expression heuristically, but a very regular
shift/mask/add sequence that simplifies naturally.
