insn-attrtab vs. VM usage

[Robert Lipe <robertl at sco dot com>]

I've been out of bootstrapsville for quite some time and am now tracking
various weirdnesses from the CVS tree on the i686 OSR5 and UW7 targets.

I can't tell if this is the new GC scheme or something else, but
during a bootstrap the optimized build of insn-attrtab.c is destroying
my VM usage.  Each system has 128Mb of core and at least that much
in available swap and a very reasonable set of processes ulimits.
Amazingly, we run out of VM sometimes.  If I build it with -O1 it
will always succeed and takes only moderately too long.  If I build
(as bootstrap does) with -O2 it usually doesn't make it out alive,
complaining "unable to allocate 2184 bytes" or some other trivial
amount.

I have another case that looks like a malloc buffer overwrite.  I'm
seeing goofy things like core dumps that go away when --save-temps is
added to the invocation.  (Honest.)  Since there are so many other forms
of weirdness going on, I think I'll defer chasing that one for a while.

This is the -Q -O1 case.  It consumes a lot of VM but not all it can
find.  The -O2 case isn't as capturable.

 getlogin_r ttyname_r mknod fstat stat lstat insn_current_length insn_variable_length_p insn_default_length result_ready_cost {GC 5555k -> 2100k in 0.090} k6_fpu_unit_ready_cost k6_fpu_unit_blockage_range k6_store_unit_ready_cost k6_load_unit_ready_cost k6_branch_unit_ready_cost k6_alu_unit_ready_cost {GC 5474k -> 1291k in 0.050} k6_alu_unit_blockage_range k6_alux_unit_ready_cost k6_alux_unit_blockage_range ppro_p34_unit_ready_cost ppro_p2_unit_ready_cost ppro_p01_unit_ready_cost ppro_p0_unit_ready_cost ppro_p0_unit_blockage_range pent_v_unit_ready_cost pent_uv_unit_ready_cost {GC 6429k -> 2442k in 0.110} pent_uv_unit_blockage_range pent_u_unit_ready_cost {GC 8779k -> 2694k in 0.120} pent_u_unit_blockage_range fpu_unit_ready_cost fpu_unit_blockage_range pent_mul_unit_ready_cost pent_mul_unit_blockage_range pent_np_unit_ready_cost {GC 8118k -> 1907k in 0.100} pent_np_unit_blockage_range function_units_used {GC 5395k -> 767k in 0.110} get_attr_fp_int_src get_attr_imm_disp get_at!
tr_length_opcode get_attr_length_prefix get_attr_memory get_attr_ppro_uops get_attr_pent_pair get_attr_type k6_fpu_unit_blockage k6_fpu_unit_conflict_cost k6_alu_unit_blockage k6_alu_unit_conflict_cost {GC 5493k -> 817k in 0.030} k6_alux_unit_blockage k6_alux_unit_conflict_cost ppro_p0_unit_blockage ppro_p0_unit_conflict_cost pent_uv_unit_blockage pent_uv_unit_conflict_cost pent_u_unit_blockage pent_u_unit_conflict_cost fpu_unit_blockage fpu_unit_conflict_cost {GC 5344k -> 869k in 0.020} pent_mul_unit_blockage pent_mul_unit_conflict_cost pent_np_unit_blockage {GC 5548k -> 2675k in 0.120} pent_np_unit_conflict_cost {GC 7916k -> 2433k in 0.100}
time in parse: 7.170000 (6%)
time in integration: 0.000000 (0%)
time in jump: 8.620000 (8%)
time in cse: 8.730000 (8%)
time in gcse: 0.000000 (0%)
time in loop: 0.050000 (0%)
time in cse2: 0.000000 (0%)
time in branch-prob: 0.000000 (0%)
time in flow: 3.820000 (3%)
time in combine: 5.640000 (5%)
time in regmove: 0.000000 (0%)
time in sched: 0.000000 (0%)
time in local-alloc: 3.020000 (3%)
time in global-alloc: 60.350000 (55%)
time in flow2: 3.070000 (3%)
time in peephole2: 0.000000 (0%)
time in sched2: 0.000000 (0%)
time in shorten-branch: 1.450000 (1%)
time in stack-reg: 0.250000 (0%)
time in final: 1.750000 (2%)
time in varconst: 0.020000 (0%)
time in symout: 0.000000 (0%)
time in dump: 0.000000 (0%)
time in gc: 0.850000 (1%)

Is there other information I can provide to help chase this down?  

RJL