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