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. 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. Thanks, Richard
