This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [029/nnn] poly_int: get_ref_base_and_extent
- From: Jeff Law <law at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org, richard dot sandiford at linaro dot org
- Date: Wed, 6 Dec 2017 13:03:36 -0700
- Subject: Re: [029/nnn] poly_int: get_ref_base_and_extent
- Authentication-results: sourceware.org; auth=none
- References: <871sltvm7r.fsf@linaro.org> <87efptpz54.fsf@linaro.org>
On 10/23/2017 11:11 AM, Richard Sandiford wrote:
> This patch changes the types of the bit offsets and sizes returned
> by get_ref_base_and_extent to poly_int64.
>
> There are some callers that can't sensibly operate on polynomial
> offsets or handle cases where the offset and size aren't known
> exactly. This includes the IPA devirtualisation code (since
> there's no defined way of having vtables at variable offsets)
> and some parts of the DWARF code. The patch therefore adds
> a helper function get_ref_base_and_extent_hwi that either returns
> exact HOST_WIDE_INT bit positions and sizes or returns a null
> base to indicate failure.
>
>
> 2017-10-23 Richard Sandiford <richard.sandiford@linaro.org>
> Alan Hayward <alan.hayward@arm.com>
> David Sherwood <david.sherwood@arm.com>
>
> gcc/
> * tree-dfa.h (get_ref_base_and_extent): Return the base, size and
> max_size as poly_int64_pods rather than HOST_WIDE_INTs.
> (get_ref_base_and_extent_hwi): Declare.
> * tree-dfa.c (get_ref_base_and_extent): Return the base, size and
> max_size as poly_int64_pods rather than HOST_WIDE_INTs.
> (get_ref_base_and_extent_hwi): New function.
> * cfgexpand.c (expand_debug_expr): Update call to
> get_ref_base_and_extent.
> * dwarf2out.c (add_var_loc_to_decl): Likewise.
> * gimple-fold.c (get_base_constructor): Return the offset as a
> poly_int64_pod rather than a HOST_WIDE_INT.
> (fold_const_aggregate_ref_1): Track polynomial sizes and offsets.
> * ipa-polymorphic-call.c
> (ipa_polymorphic_call_context::set_by_invariant)
> (extr_type_from_vtbl_ptr_store): Track polynomial offsets.
> (ipa_polymorphic_call_context::ipa_polymorphic_call_context)
> (check_stmt_for_type_change): Use get_ref_base_and_extent_hwi
> rather than get_ref_base_and_extent.
> (ipa_polymorphic_call_context::get_dynamic_type): Likewise.
> * ipa-prop.c (ipa_load_from_parm_agg, compute_complex_assign_jump_func)
> (get_ancestor_addr_info, determine_locally_known_aggregate_parts):
> Likewise.
> (ipa_get_adjustment_candidate): Update call to get_ref_base_and_extent.
> * tree-sra.c (create_access, get_access_for_expr): Likewise.
> * tree-ssa-alias.c (ao_ref_base, aliasing_component_refs_p)
> (stmt_kills_ref_p): Likewise.
> * tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Likewise.
> * tree-ssa-scopedtables.c (avail_expr_hash, equal_mem_array_ref_p):
> Likewise.
> * tree-ssa-sccvn.c (vn_reference_lookup_3): Likewise.
> Use get_ref_base_and_extent_hwi rather than get_ref_base_and_extent
> when calling native_encode_expr.
> * tree-ssa-structalias.c (get_constraint_for_component_ref): Update
> call to get_ref_base_and_extent.
> (do_structure_copy): Use get_ref_base_and_extent_hwi rather than
> get_ref_base_and_extent.
> * var-tracking.c (track_expr_p): Likewise.
>
I initially missed some of the additional checks performed by
get_ref_base_and_extend_hwi and thought we had a problem with the
transition to use that routine in various places. But eventually I saw
the light.
OK.
jeff