This is the mail archive of the
mailing list for the GCC project.
Re: PR 30089: Fix ICE in operand allocation
> Jan Hubicka wrote on 12/14/06 11:24:
> >>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.
> >looks like I incorrectly blamed you instead of myself. At least one
> >problem is that statement annotation grew up rather than reduced with my
> >histogram change. This is because I moved bitfields down in the
> >structure to allow better packing on 64bit and wrongly updated after
> >your merge.
> OK. I did one run with a reduced buffer size but, strangely, in some
> cases I got slight memory usage *increases*. I only test by looking at
> the last column of -ftime-report, so I don't know how precise that is.
> Would you mind testing this in your memory tester?
I can't easilly drop the patch into tester to test, but I will give it a
try by hand tomorrow. The reordering of fields apparently saved 6% of
the 12% insn-attrtab regression (so the mem use is 119 instead of 113K).
The other smaller changes remained, but they are quite likely unrelated
to your patch (as they show up as difference to GGC memory usage, but
the operand memory is malloced) and not that worthwhile.
So I would declare the problem solved ;)
> Index: tree-ssa-operands.h
> --- tree-ssa-operands.h (revision 119857)
> +++ tree-ssa-operands.h (working copy)
> @@ -116,7 +116,7 @@ struct vuse_optype_d
> typedef struct vuse_optype_d *vuse_optype_p;
> -#define SSA_OPERAND_MEMORY_SIZE (511 * sizeof (struct vuse_optype_d))
> +#define SSA_OPERAND_MEMORY_SIZE (95 * sizeof (struct vuse_optype_d))
> struct ssa_operand_memory_d GTY((chain_next("%h.next")))