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 <sa...@gcc.gnu.org>: https://gcc.gnu.org/g:050fc8b27a852007f8bb667999e1c8cfd31f90e1 commit r11-2851-g050fc8b27a852007f8bb667999e1c8cfd31f90e1 Author: Roger Sayle <ro...@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 <ro...@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.
