This is the mail archive of the
mailing list for the GCC project.
Re: PR 30089: Fix ICE in operand allocation
On Thu, 2006-12-14 at 15:53 +0100, Richard Guenther wrote:
> On 12/14/06, Andrew MacLeod <firstname.lastname@example.org> wrote:
> > On Thu, 2006-12-14 at 07:31 -0500, Diego Novillo wrote:
> > > Jan Hubicka wrote on 12/14/06 05:33:
> > > > 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.
> > It would be odd if this was responsible for a measurable increase in
> > memory. Its simply the size of the buffer we create to sub-allocate
> > operands out of.
> Err - how could we then ICE running out of space there? Why don't we
> simply allocate another one?
> I'm sure I'm missing something...
The ICE was because the buffer was too small to fit the size of the VUSE
operand being requested. With the original value, the buffer only fit
about 51 64 bit VUSE operands on a single stmt, and there was a request
for 68 in that function. The facility to handle larger operands than
the buffer fits has been purposely avoided so far allowing us to make
sure we don't go too wonky with unreasonably large lists of operands on
Diego bumping it to 512 seems like a reasonable number for now.