[PATCH] Use vec::reserve before vec_safe_grow_cleared is called

[Richard Biener]

On Mon, Jul 27, 2020 at 1:24 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 7/27/20 1:11 PM, Jan Hubicka wrote:
> >> On 7/27/20 9:11 AM, Richard Biener wrote:
> >>> OK.  I guess the previous code tried to use less memory.
> >>
> >> It did. But I didn't realize that such exact growth would lead
> >> to a massive reallocation for huge apps like chromium.
> >
> > I would consider it an API issue - it is not really at all that obvious
> > when vec API does auto reserve and when it does not.
>
> Fully agree here, it's super-confusing.
>
> >
> > Grepping for vec_safe_grow, rtl_create_basic_block, gimple_set_bb,
> > extend_h_i_d, stack_regs_mentioned, init_deps_data_vector
> > extend_insn_data, create_bb, move_block_to_fn logic has similar logic
> > but implemented by hand.  Perhaps we can switch it to the new API.
> >
> > combine_split_insns, combine_instructions, update_row_reg_save,
> > grow_label_align, update_uses, final_warning_record::grow_type_warnings,
> > sem_function::bb_dict_test, ::add_single_to_queue,
> > symtab_node::create_reference, mark_phi_for_rewrite, addr_for_mem_ref,
> > multiplier_allowed_in_address_p, get_address_cost_ainc,
> > make_ssa_name_fn, add_to_value, phi_translate_1,
> > optimize_range_tests_cmp_bitwise, set_strinfo,
> > ssa_name_values.safe_grow_cleared, vect_record_loop_mask has similarly
> > suspicious logic in it.
>
> Are you talking about changing all '*gros*' calls to use exact=false, right?
> I can experiment with that.

No, add gro*_exact variants and replace existing ones with this, then switch
to exact = false for the non-_exact variants.  Or add a exact=false argument
to all of them and make all existing calls explicitly passing true.

Only later, on a case by case basis, swap one for the other when obvious.

Richard.

> Martin
>
> >
> > Honza
> >>
> >> I'm going to backport the patch older releases as well.
> >>
> >> Martin
>