On Tue, 5 May 2020, Jakub Jelinek wrote: > 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).
OK, fair enough. > > 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). Yes. The question is whether we can do better than umulv4 when we know the second constant operand? Guess we can do this as followup if you like... So the original is OK. Thanks, Richard.
