Bug 38583 - huge test case makes register allocator run out of memory while constructing the conflict graph
Summary: huge test case makes register allocator run out of memory while constructing ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.4.0
: P2 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: memory-hog, ra
Depends on:
Blocks: 38474
  Show dependency treegraph
 
Reported: 2008-12-20 11:19 UTC by Joost VandeVondele
Modified: 2009-01-27 16:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-12-20 15:47:51


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joost VandeVondele 2008-12-20 11:19:47 UTC
This is split off from PR38474 for clarity. Compiling the testcase of that PR 

(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)

as

gfortran -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3
-march=native -funroll-loops -fno-rename-registers testcase.f90

requires ~9.3Gb of RAM with mainline, while 4.3 only requires ~2.5Gb.
Comment 1 Vladimir Makarov 2008-12-30 14:33:52 UTC
 I don't think that the problem occurred because of transition to IRA.  The old register allocator (-fno-ira) uses about the same size conflict table and peak virtual memory (it is 9230MB for the old RA on this case).  So original reason for the degradation is in some other compiler changes.

  Saying that we still need to prevent building huge conflict tables (although the old RA and IRA have sophisticated algorithms for the table compression resulting to 2000 times smaller size in some extreme cases).  I'll make patch to prevent building conflicts and to use allocation without allocno conflicts for such extreme cases on next week.
Comment 2 Steven Bosscher 2009-01-03 17:23:55 UTC
I agree with Vlad, this is not a regression.

It'd still be nice if you can figure out a way to make this work, Vlad.  It is possible, perhaps, to split huge basic blocks up in chunks (e.g. separate basic blocks or regions) and allocate the chunks separately?

Comment 3 Vladimir Makarov 2009-01-06 03:50:20 UTC
Subject: Bug 38583

Author: vmakarov
Date: Tue Jan  6 03:50:07 2009
New Revision: 143112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143112
Log:
2009-01-05  Vladimir Makarov  <vmakarov@redhat.com>

	PR rtl-optimization/38583
	* params.h (IRA_MAX_CONFLICT_TABLE_SIZE): New macro.

	* params.def (ira-max-conflict-table-size): New.

	* doc/invoke.texi (ira-max-conflict-table-size): Decribe.
	
	* ira.h (ira_conflicts_p): New external definition.
	
	* ira-conflicts.c (build_conflict_bit_table): Do not build too big
	table.  Report this.  Return result of building.
	(ira_build_conflicts): Use ira_conflicts_p.  Check result of
	building conflict table.

	* ira-color.c (fast_allocation): Use num instead of
	ira_allocnos_num.
	(ira_color): Use ira_conflicts_p.
	
	* global.c: Include ira.h.
	(pseudo_for_reload_consideration_p, build_insn_chain): Use
	ira_conflicts_p.

	* Makefile.in (global.o): Add ira.h.
	
	* ira-build.c (mark_all_loops_for_removal,
	propagate_some_info_from_allocno): New.
	(remove_unnecessary_allocnos): Call
	propagate_some_info_from_allocno.
	(remove_low_level_allocnos): New.
	(remove_unnecessary_regions): Add parameter.  Call
	mark_all_loops_for_removal and remove_low_level_allocnos.  Pass
	parameter to remove_unnecessary_regions.
	(ira_build): Remove all regions but root if the conflict table was
	not built.  Update conflict hard regs for allocnos crossing calls.

	* ira.c (ira_conflicts_p): New global.
	(ira): Define and use ira_conflicts_p.

	* reload1.c (compute_use_by_pseudos, reload, count_pseudo,
	count_spilled_pseudo, find_reg, alter_reg, finish_spills,
	emit_input_reload_insns, delete_output_reload): Use
	ira_conflicts_p.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/doc/invoke.texi
    trunk/gcc/global.c
    trunk/gcc/ira-build.c
    trunk/gcc/ira-color.c
    trunk/gcc/ira-conflicts.c
    trunk/gcc/ira.c
    trunk/gcc/ira.h
    trunk/gcc/params.def
    trunk/gcc/params.h
    trunk/gcc/reload1.c

Comment 4 H.J. Lu 2009-01-27 16:50:34 UTC
(In reply to comment #0)
> This is split off from PR38474 for clarity. Compiling the testcase of that PR 
> 
> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
> 
> as
> 
> gfortran -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3
> -march=native -funroll-loops -fno-rename-registers testcase.f90
> 
> requires ~9.3Gb of RAM with mainline, while 4.3 only requires ~2.5Gb.
> 

This testcase failed to compile with gcc 4.3.4 143496:

/usr/gcc-4.3/bin/gcc -S -march=native -funroll-loops -fno-rename-registers -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3 testcase.f90 -fmem-report
f951: out of memory allocating 6998974688 bytes after a total of 674205696 bytes

on Linux/Intel64 with 4GB RAM and 2GB swap. Gcc 4.4.0 revision 143680
compiles it on the same machine.