This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Trim down cselib memory usage


> Jan Hubicka <jh@suse.cz> writes:
> 
> > 2004-01-20  Jan Hubicka  <jh@suse.cz>
> > 	* cselib.c: Include alloc-pool.h
> > 	(empty_vals, empty_elt_lists, empty_elt_loc_lists): Kill.
> > 	(elt_loc_list_pool, elt_list_pool, cselib_val_pool): Declare.
> > 	(new_elt_list, new_elt_loc_list, unchain_one_elt_list,
> > 	unchain_one_elt_loc_list_pool, unchain_one_value,
> > 	new_cselib_val): Simplify using allocpool.
> > 	(cselib_init): Initialize allocpools.
> > 	(cselib_finish): Finish allocpools.
> 
> This patch (together with
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02536.html) breaks
> ia64-linux bootstrap.
> 
> stage1/xgcc -Bstage1/ -B/usr/local/ia64-suse-linux/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -Werror -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include  ../../gcc/c-decl.c -o c-decl.o
> ../../gcc/c-decl.c: In function `xref_tag':
> ../../gcc/c-decl.c:4737: internal compiler error: Segmentation fault

In fact I was discussing this with Jakub already (he pointed out to me
his patch http://gcc.gnu.org/ml/gcc/2003-07/msg00780.html
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01683.html
and my sanity checking patch just made this bug more reproducible as I
do invalidate the value instead of overwriting it by something sanely
looking).

I think the solution shall be to simply avoid recycling the values when
cselib is used from scheduler.  The memory usage is not completely
catastrophical (it is dominated by size of function RTL representation)
and with allocpool we can get rid of it cheaply.

Does the attached patch help?  I was trying to get it tested by Zdenek's
tester but can't get results as it just claims that clean branch is
broken.

Please, if you will get into testing it, use checking.

Honza

Index: alloc-pool.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alloc-pool.c,v
retrieving revision 1.10
diff -c -3 -p -r1.10 alloc-pool.c
*** alloc-pool.c	23 Jan 2004 22:01:55 -0000	1.10
--- alloc-pool.c	25 Jan 2004 00:14:42 -0000
*************** free_alloc_pool (alloc_pool pool)
*** 149,154 ****
--- 149,157 ----
    for (block = pool->block_list; block != NULL; block = next_block)
      {
        next_block = block->next;
+ #ifdef ENABLE_CHECKING
+       memset (block, 0xaf, pool->block_size);
+ #endif
        free (block);
      }
    /* Lastly, free the pool and the name.  */
Index: cselib.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cselib.c,v
retrieving revision 1.36
diff -c -3 -p -r1.36 cselib.c
*** cselib.c	24 Jan 2004 00:38:50 -0000	1.36
--- cselib.c	25 Jan 2004 00:14:44 -0000
*************** cselib_process_insn (rtx insn)
*** 1366,1373 ****
--- 1366,1375 ----
  
    cselib_current_insn = 0;
  
+ #if 0
    if (n_useless_values > MAX_USELESS_VALUES)
      remove_useless_values ();
+ #endif
  }
  
  /* Make sure our varrays are big enough.  Not called from any cselib routines;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]