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
