On Fri, Nov 24, 2017 at 07:19:29PM -0600, Segher Boessenkool wrote:
> Hi,
>
> On Fri, Nov 24, 2017 at 10:38:13PM +0100, Jakub Jelinek wrote:
> > The following testcase ICEs in wide-int*, but the reason is a mode mismatch
> > (we build a SImode MULT with one QImode argument and one VOIDmode argument,
> > then it is folded into SImode NEG with QImode argument, ...).
> > The bug is in assuming that the mode of c1 must be m, that is usually the
> > case, but shifts are special, the second argument can have a different mode.
> >
> > The following patch makes sure we perform the computation of the new shift
> > count in the right mode.
>
> Okay, thanks! Is this better than bailing out though, do you have
> an example?
I don't, but I haven't bootstrapped/regtested with a patch to gather
statistics on whether it would ever be successful (how? Should I note in a
flag successful optimization of this and then check that flag upon
successful try_combine and clear it at the end of any try_combine? It would
need to be done for all targets probably). This code dates from 1994, but
testsuite was separate, so it is hard to check if this was covered by any
testcases.
If C1 is a constant (but then it would likely have VOIDmode), then I can
imagine it would match, though hard to find testcases, because usually
GIMPLE folding should propagate constants far earlier. If C1 is a pseudo,
then we'd need an instruction that has
(any_shift (something) (mult (something) (something)))
which is quite unlikely. But it is similarly unlikely for
(ior (something) (mult (something) (something))) and similar.
Or can try_combine then split it into two separate instructions, one doing
the mult and one doing the other, say when combining from original 3 or 4
instructions? If so, then it could be likely it hits.
Jakub
