divmod: Match and expand DIVMOD even in some cases of constant divisor [PR97282]

As written in the comment, tree-ssa-math-opts.c wouldn't create a DIVMOD
ifn call for division + modulo by constant for the fear that during
expansion we could generate better code for those cases.
If the divisoris a power of two, that is certainly the case always,
but otherwise expand_divmod can punt in many cases, e.g. if the division
type's precision is above HOST_BITS_PER_WIDE_INT, we don't even call
choose_multiplier, because it works on HOST_WIDE_INTs (true, something
we should fix eventually now that we have wide_ints), or if pre/post shift
is larger than BITS_PER_WORD.

So, the following patch recognizes DIVMOD with constant last argument even
when it is unclear if expand_divmod will be able to optimize it, and then
during DIVMOD expansion if the divisor is constant attempts to expand it as
division + modulo and if they actually don't contain any libcalls or
division/modulo, they are kept as is, otherwise that sequence is thrown away
and divmod optab or libcall is used.

2020-10-06  Jakub Jelinek  <jakub@redhat.com>

	PR rtl-optimization/97282
	* tree-ssa-math-opts.c (divmod_candidate_p): Don't return false for
	constant op2 if it is not a power of two and the type has precision
	larger than HOST_BITS_PER_WIDE_INT or BITS_PER_WORD.
	* internal-fn.c (contains_call_div_mod): New function.
	(expand_DIVMOD): If last argument is a constant, try to expand it as
	TRUNC_DIV_EXPR followed by TRUNC_MOD_EXPR, but if the sequence
	contains any calls or {,U}{DIV,MOD} rtxes, throw it away and use
	divmod optab or divmod libfunc.

	* gcc.target/i386/pr97282.c: New test.

0 files changed, 0 insertions, 0 deletions