Re: PR 30089: Fix ICE in operand allocation

[Diego Novillo <dnovillo at redhat dot com>]

Jan Hubicka wrote on 12/14/06 05:33:
> > In the second testcase of this PR, we are creating very many
> > subvariables for one of the structures in the code.  Since these
> > sub-variables happen to be unaliased, we are adding a VUSE operand for
> > each of them.
> >
> > Andrew suggested to re-state this limit in terms of operands, instead
> > of bytes.  He is re-working the code to support multiple-operands and
> > he will likely make this limit more flexible.
> >
> > We should however, notice that we are trying to add an unreasonable
> > number of virtual operands.  Though, ICEing is perhaps not the kindest
> > way.
> >
> > Setting this limit to 511 operands for now (an extra pointer is taken
> > up by the buffer).
> >
> > The test still takes a lot more memory than it probably should.  I
> > will be working on that. I have cc1plus topping at 1Gb on x86_64.  But
> > the alias analysis times are more reasonable:
>
> Hi,
> I would say that this patch is the most likely suspect for memory
> increase reported for this night. (memory tester jammed, so there are
> quite few patches cumulated together).
> It is 12% for insn-attrtrab, but we are still bellow memory usage before
> your merge and above memory usage before original Daniel's aliasing
> fixes (that was about 100MB, now we are almost 130)
It may be, yes.  We shouldn't need the static buffer for long, 
hopefully.  Andrew is changing this code.  I will try to adjust it down 
in the meantime.