hppa: PR middle-end/87256: Improved hppa_rtx_costs avoids synth_mult madness.

hppa: PR middle-end/87256: Improved hppa_rtx_costs avoids synth_mult madness.

This is my proposed fix to PR middle-end/87256 where synth_mult takes an
unreasonable amount of CPU time determining an optimal sequence of
instructions to perform multiplication by (large) integer constants on hppa.
One workaround proposed in bugzilla, is to increase the hash table used
to cache/reuse intermediate results. This helps but is a workaround for
the (hidden) underlying problem.

The real issue is that the hppa_rtx_costs function is providing wildly
inaccurate values (estimates) to the middle-end.  For example, (p*q)+(r*s)
would appear to be cheaper than a single multiplication.  Another
example is that "(ashiftrt:di regA regB)" is claimed to be only be
COST_N_INSNS(1) when in fact the hppa backend actually generates
slightly more than a single instruction.

It turns out that simply tightening up the logic in hppa_rtx_costs to
return more reasonable values, dramatically reduces the number of recursive
invocations in synth_mult for the test case in PR87256, and presumably
also produces faster code (that should be observable in benchmarks).

2020-08-25  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	PR middle-end/87256
	* config/pa/pa.c (hppa_rtx_costs_shadd_p): New helper function
	to check for coefficients supported by shNadd and shladd,l.
	(hppa_rtx_costs):  Rewrite to avoid using estimates based upon
	FACTOR and enable recursing deeper into RTL expressions.