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: [RFC] PR c/12245 (not really C frontend issue)


> On Mon, 23 Feb 2009, Jan Hubicka wrote:
> 
> > > On Sun, 22 Feb 2009, Jan Hubicka wrote:
> > > 
> > > > Hi,
> > > > the testcase of PR contains one large initializer all of constant 18.
> > > > This shows problem in a way we construct a constructors.  One problem
> > > > mentioned by Richi (and he hopefuly have patch) is that we use
> > > > INTEGER_CST to count the indices that makes us to build constants
> > > > 1.....large_number.
> > > 
> > > See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00091.html for a
> > > failed attempt to fix that.  The response was that a proper
> > > fix is to build a (sparse) target representation of the initializer
> > > to which I agree, but of course this is way more work.
> > 
> > Yep, the flat replrezentation of initializers is one part of problem,
> > not needing a lot of temporary trees is other.
> > Can we possibly break out the HOST_WIDE_INT bits for temporary counters?
> 
> IIRC the exact same counters are stuck into the CONSTRUCTOR, so we
> won't save anything there.

Well, from stats there are 70MB temporary integers that are garbage
collected out even when CONSTUCTOR is still there, so some temporary
nodes are still born...
perhaps different types again?  I will take a look.

Honza
> 
> Richard.


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