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.sandif...@linaro.org> > Alan Hayward <alan.hayw...@arm.com> > David Sherwood <david.sherw...@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
