[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:050fc8b27a852007f8bb667999e1c8cfd31f90e1

commit r11-2851-g050fc8b27a852007f8bb667999e1c8cfd31f90e1
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Tue Aug 25 19:02:45 2020 +0100

    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.