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

Roger Sayle roger@nextmovesoftware.com
Fri Aug 21 18:41:08 GMT 2020

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 multiplications by (large) integer constants on
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 (more subtle) 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
COST_N_INSNS(1) when in fact the hppa backend actually generates:

ashrdi: ldi 32,%r28
        and %r24,%r28,%r28
        comib,= 0,%r28,.L6
        mtsar %r24
        subi 31,%r24,%r24
        extrs %r25,0,1,%r28
        mtsar %r24
        bv %r0(%r2)
        vextrs %r25,32,%r29
.L6:    uaddcm %r0,%r24,%r28
        vshd %r0,%r26,%r29
        subi 31,%r28,%r28
        mtsar %r28
        zdep %r25,30,31,%r19
        subi 31,%r24,%r24
        zvdep %r19,32,%r19
        mtsar %r24
        or %r19,%r29,%r29
        bv %r0(%r2)
        vextrs %r25,32,%r28

which is 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).

Unfortunately, once again this has only be tested via cross-compilers
to hppa-unknown-linux-gnu and hppa64-unknown-linux-gnu hosted on
x86_64-pc-linux-gnu, but I can confirm cross-compilation is much faster.
Many thanks in advance to anyone who can bootstrap and regression test
this on real hardware.  In an ideal world, changes to rtx_costs should
be pretty safe, this function can't introduce any bugs, only expose those
are already present (but possibly latent) elsewhere in the compiler.  Ha.

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

	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.

Thanks again.
Roger Sayle
NextMove Software
Cambridge, UK

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchh2.txt
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200821/ada847da/attachment.txt>

More information about the Gcc-patches mailing list