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: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2

From: bernds_cb1 at t-online dot de (Bernd Schmidt)
To: Geert Bosch <bosch at adacore dot com>
Cc: gcc-patches at gcc dot gnu dot org, Kazu Hirata <kazu at cs dot umass dot edu>
Date: Mon, 31 Jan 2005 18:19:57 +0100
Subject: Re: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
References: <20050130.094140.59467285.kazu@cs.umass.edu> <41FE42FB.9050203@t-online.de> <20050131.101546.71112414.kazu@cs.umass.edu> <41FE536F.9050103@t-online.de> <BB26A056-73A7-11D9-B68A-000393754BEA@adacore.com>

Geert Bosch wrote:

Growing the table by anything else than a constant factor will
result in quadratic behavior.

Hmm. How so? This allocation happens twice per function in the worst case. This worst case can be triggered with both strategies.

> It's not so bad to allocate a bit too

much VM, as long as we don't touch more memory than we need to.

You do have a point there. Kazu, if you change the patch to initialize [previous_maxreg .. current_maxreg] instead of [old_size .. new_size], it's OK too.

Bernd

Follow-Ups:
- Re: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
  - From: Kazu Hirata

References:
- [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
  - From: Kazu Hirata
- Re: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
  - From: Bernd Schmidt
- Re: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
  - From: Kazu Hirata
- Re: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
  - From: Bernd Schmidt
- Re: [patch] cse.c: Speed up cse_reg_info maintainance - Part 2
  - From: Geert Bosch

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