On 01/12/2018 06:31 AM, Richard Sandiford wrote: > Richard Sandiford <richard.sandif...@linaro.org> writes: >> 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. > > It turns out that the only two parts needed to build an SVE toolchain are > the gimplify.c change I mentioned above and the tree-vectorizer.c change. > I'll reply with individual patches for those. I'd still like to fix the > DR_INIT uses too, even though I no longer have a specific example that > needs it. THanks for splitting those out.
> > None of the other changes are needed to get clean test results or > when building the benchmarks that we've been using for SVE, so I'm > happy to leave those to GCC 9 if you think that's better. > > None of the changes in the corresponding rtl patch seem to be needed > for correctness. I'm certainly looking to reduce the churn at this point :-) Obviously if something comes up and we see a need we can address it. I wouldn't be terribly surprised if that happens over time. jeff
