Re: [015/nnn] poly_int: ao_ref and vn_reference_op_t

[Jeff Law <law at redhat dot com>]

On 10/23/2017 11:06 AM, Richard Sandiford wrote:
> This patch changes the offset, size and max_size fields
> of ao_ref from HOST_WIDE_INT to poly_int64 and propagates
> the change through the code that references it.  This includes
> changing the off field of vn_reference_op_struct in the same way.
> 
> 
> 2017-10-23  Richard Sandiford  <richard.sandiford@linaro.org>
> 	    Alan Hayward  <alan.hayward@arm.com>
> 	    David Sherwood  <david.sherwood@arm.com>
> 
> gcc/
> 	* inchash.h (inchash::hash::add_poly_int): New function.
> 	* tree-ssa-alias.h (ao_ref::offset, ao_ref::size, ao_ref::max_size):
> 	Use poly_int64 rather than HOST_WIDE_INT.
> 	(ao_ref::max_size_known_p): New function.
> 	* tree-ssa-sccvn.h (vn_reference_op_struct::off): Use poly_int64_pod
> 	rather than HOST_WIDE_INT.
> 	* tree-ssa-alias.c (ao_ref_base): Apply get_ref_base_and_extent
> 	to temporaries until its interface is adjusted to match.
> 	(ao_ref_init_from_ptr_and_size): Handle polynomial offsets and sizes.
> 	(aliasing_component_refs_p, decl_refs_may_alias_p)
> 	(indirect_ref_may_alias_decl_p, indirect_refs_may_alias_p): Take
> 	the offsets and max_sizes as poly_int64s instead of HOST_WIDE_INTs.
> 	(refs_may_alias_p_1, stmt_kills_ref_p): Adjust for changes to
> 	ao_ref fields.
> 	* alias.c (ao_ref_from_mem): Likewise.
> 	* tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Likewise.
> 	* tree-ssa-dse.c (valid_ao_ref_for_dse, normalize_ref)
> 	(clear_bytes_written_by, setup_live_bytes_from_ref, compute_trims)
> 	(maybe_trim_complex_store, maybe_trim_constructor_store)
> 	(live_bytes_read, dse_classify_store): Likewise.
> 	* tree-ssa-sccvn.c (vn_reference_compute_hash, vn_reference_eq):
> 	(copy_reference_ops_from_ref, ao_ref_init_from_vn_reference)
> 	(fully_constant_vn_reference_p, valueize_refs_1): Likewise.
> 	(vn_reference_lookup_3): Likewise.
> 	* tree-ssa-uninit.c (warn_uninitialized_vars): Likewise.
It looks like this patch contains more changes from ranges_overlap_p to
ranges_may_overlap_p.  They aren't noted in the ChangeLog.

As I look at these patches my worry is we're probably going to need some
guidance in our documentation for when to use the poly interfaces.
Certainly the type system helps here, so someone changing existing code
will likely get errors at compile time if they goof.  But in larger
chunks of new code I won't be surprised if problems creep in until folks
adjust existing habits.

As is often the case, there's a certain amount of trust here that you
evaluated the may/must stuff correctly.  It was fairly easy for me to
look at the tree-ssa-dse.c changes and see the intent as I'm reasonably
familiar  with that code.   tree-ssa-sccvn (as an example) is much
harder for me to evaluate.

OK.

jeff