On Tue, May 05, 2020 at 09:21:13AM +0200, Richard Biener wrote:
> > On x86 (the only target with umulv4_optab) one can use mull; seto to check
> > for overflow instead of performing wider multiplication and performing
> > comparison on the high bits.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Hmm. The preceeding pattern doesn't check for umulv4 availability, so
> why do it here?
I admit I have even considered adding the check to the preceeding pattern,
but the preceeding pattern performs division which is most likely more
costly than e.g. highpart multiply or whatever the .MUL_OVERFLOW will expand
to when umulv4_optab isn't available.
This pattern is in the form that it can be matched by highpart multiply, or
widening multiply etc., so it doesn't seem worth changing it into the
.MUL_OVERFLOW form where it will need more IL and the end effect will be
(most likely) the same, but can't be sure about that (.MUL_OVERFLOW in
corner cases can be pretty large inline code).
> I suppose an alternative simplification would be
> to use a highpart multiply? Do you intentionally not consider
> ((type)A * CST) >> prec?
I guess I could do (convert? @1) and then in the if condition check that
either @1 is INTEGER_CST that has the upper bits all clear, or
types_match (@0, @1).
Jakub
