On Mon, Jul 27, 2020 at 1:24 PM Martin Liška <mli...@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 >
