On Mon, Dec 7, 2020 at 4:30 PM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> Hi!
>
> On Mon, Dec 07, 2020 at 03:27:14PM +0100, Uros Bizjak wrote:
> > On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
> > <seg...@kernel.crashing.org> wrote:
> > > A splitter can *already* split to only one insn.
> >
> > Unfortunately, the attached patch with the following testcase:
> >
> > --cut here--
> > int test (int a, int b)
> > {
> > return a << (b & 31);
> > }
> > --cut here--
> >
> > does not trigger the call to combine_split_insns. The reason in the
> > following condition:
> >
> > /* If we were combining three insns and the result is a simple SET
> > with no ASM_OPERANDS that wasn't recognized, try to split it into two
> > insns. There are two ways to do this. It can be split using a
> > machine-specific method (like when you have an addition of a large
> > constant) or by combine in the function find_split_point. */
> >
> > if (i1 && insn_code_number < 0 && GET_CODE (newpat) == SET
> > && asm_noperands (newpat) < 0)
> >
> > where i1 is null.
>
> I see. We could also allow this for 2->2 combinations (w/ the same
> restrictions we do for other 2->2 combinations, but that probably falls
> out automatically).
>
> This will need careful testing of course, but I don't expect anything
> bad (famous last words of course).
>
> Could you please open a PR for this? Just so I can keep track :-)
I have opened PR98178.
Thanks,
Uros.
