Hello, VEC_reserve allocates an *extra* number of slots. There is unfortunately no VEC_resize op (one of the first things to add after the merge of the cxx branch, I suppose...), so to "grow" a VEC without increasing the used slots count (the VEC_length) it's necessary to compute the number of extra slots needed and reserve only that number of slots.
So something like:
VEC_reserve (ssa_name_info_p, heap, info_for_ssa_name, num_ssa_names);
on an existing VEC with non-null length is wrong. In the worst case,
the VEC_length is already num_ssa_names and the VEC ends up twice as
large as necessary.
Another thing I noticed, is that in update_ssa() we're
sbitmap_zero'ing new_ssa_names and old_ssa_names even after we've
already done so in init_update_ssa. This might seem like a
micro-optimization, but it cuts the time spent in the timevar "tree
SSA incremental" in half for the test case of PR54146...
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
vec_reserve.diff
Description: Binary data
