> 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. 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. Honza > > I'm going to backport the patch older releases as well. > > Martin
