Jeff Law <l...@redhat.com> writes: > On 01/09/2018 11:39 AM, Richard Sandiford wrote: >> This patch generalises various places that used hwi tree accessors >> so that they can handle poly_ints instead. Earlier patches did >> this while updating interfaces; this patch just mops up some >> left-over pieces that weren't necessary to make things compile, >> but that still make sense. >> >> In many cases these changes are by inspection rather than because >> something had shown them to be necessary. >> >> I think the alias.c part is a minor bug fix: previously we used >> fits_uhwi_p for a signed HOST_WIDE_INT (which the caller does >> treat as signed rather than unsigned). We also checked whether >> each individual offset overflowed but didn't check whether the >> sum did. >> >> Sorry for not posting this earlier. I kept holding it back in case >> more examples showed up. >> >> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. >> Also tested by comparing the before-and-after assembly output for at >> least one target per CPU directory. OK to install? >> >> Richard >> >> >> 2018-01-09 Richard Sandiford <richard.sandif...@linaro.org> >> >> gcc/ >> * alias.c (adjust_offset_for_component_ref): Use poly_int_tree_p >> and wi::to_poly_offset. Add the current offset and then check >> whether the sum fits, rather than using an unchecked addition of >> a checked term. Check for a shwi rather than a uhwi. >> * expr.c (get_bit_range): Use tree_to_poly_uint64. >> (store_constructor): Use poly_int_tree_p. >> (expand_expr_real_1): Likewise. >> * function.c (assign_temp): Likewise. >> * fold-const.c (const_binop): Use poly_int_tree_p and >> wi::to_poly_offset. >> (fold_indirect_ref_1): Likewise. Use known_in_range_p to test >> for an in-range vector access and multiple_p to attempt an exact >> division. >> * gimplify.c (gimple_add_tmp_var_fn): Use tree_fits_poly_uint64_p. >> (gimple_add_tmp_var): Likewise. >> * ipa-icf-gimple.c (func_checker::compare_operand): Use >> to_poly_offset for MEM offsets. >> * ipa-icf.c (sem_variable::equals): Likewise. >> * stor-layout.c (compute_record_mode): Use poly_int_tree_p. >> * tree-vectorizer.c (get_vec_alignment_for_array_type): Likewise. >> * tree-predcom.c (aff_combination_dr_offset): Use wi::to_poly_widest >> rather than wi::to_widest for DR_INITs. >> * tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use >> wi::to_poly_offset for BIT_FIELD_REF offsets. >> (vn_reference_maybe_forwprop_address): Use poly_int_tree_p and >> wi::to_poly_offset. >> * tree-vect-data-refs.c (vect_find_same_alignment_drs): Use >> wi::to_poly_offset for DR_INIT. >> (vect_analyze_data_ref_accesses): Require both DR_INITs to be >> INTEGER_CSTs. >> (vect_analyze_group_access_1): Note that here. >> * var-tracking.c (emit_note_insn_var_location): Use >> tree_to_poly_uint64. > How important is this? We're just about to move into stage4 and this > feels a bit more like something we should do in stage1.
The gimplify.c part is needed in order to build libgfortran for SVE. There were certainly failures without the DR_INIT changes too. I think at least some of the others are also needed to fix test failures, but after a certain point I tried to proactively convert code rather than wait for a testcase to show up why. Sorry for not keeping better notes. Most of these changes are old -- the gimplify.c part has been around for a year and half -- but I was trying to roll stuff up to avoid posting too many patches of this kind. I can try to redo it so that it*s only shwi->poly_int64 and uhwi->poly_uint64 (and so drop things like the alias.c bounds checking fix) if that seems safer at this stage. Richard
