In some large functions, where all hardware registers are "used
up" and some pseudo-register need to be allocated on stack,
EXTRA_MEMORY_CONSTRAINT will have a pessimizing effect. Without
further analysis, it seems that it causes pseudo-registers to be
committed ("too devoted") to memory with no apparent re-use of
registers, if any free one is found later on (perhaps as part of
reload inheritance). I compared LAST_UPDATED: "Sun Feb 27 17:43:10
UTC 2005" without (0) and with (1) the patch at <URL:> and also with
the patch applied except the EXTRA_MEMORY_CONSTRAINT definition
(2) (the removal of that line and the atomicity.h patch to avoid
build failure). For ghostscript-5.50 (patched to submission for
current trunk) and the minimal input in the attachment named
test.ps, emitting png, the longest_match function (from zlib 1.1.3)
in the attached test-case (attachment bigfun.i) was part of an
execution path with similar other pessimizations observed.
Numbers are simulated schedulable cycles. 0, baseline:
495989262. 1, E_M_C: 498036429 (time-ratio vs baseline:
100.41%). 2, Q-fixes but no E_M_C was identical to baseline.
Note differences in between "baseline" and "fixed-Q-and-E_M_C"
in the generated assembly code (baseline and diff to be attached).
Compiled with "-O2 -march=v10 -mno-mul-bug-workaround".
--
Summary: Pessimizing effects of defining EXTRA_MEMORY_CONSTRAINT
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cris-axis-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20242
