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

[Martin Liška]

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.

Martin

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