https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #25 from Yuri Rumyantsev <ysrumyan at gmail dot com> --- Richard! I prepared the second part of patch and checked that it does not produce any new failures. What is your opinion - could I send it to GCC community for review? ChangeLog: 2016-06-10 Yuri Rumyantsev <ysrum...@gmail.com> PR tree-optimization/70729 * tree-ssa-loop-im.c (gather_mem_refs_stmt): Mark loop as having unanalyzed memory references. (ref_indep_loop_p_1): Consider memory reference as independent in loops having positive safelen value and not having unanalyzed memory references. (tree_ssa_lim_finalize): Clear-up aux field of loops. * tree-vect-loop.c (vect_transform_loop): Clear-up safelen value since it may be not valid after vectorization. gcc/testsuite/ChangeLog * g++.dg/vect/pr70729.cc: New test. 2016-06-09 9:42 GMT+03:00 rguenther at suse dot de <gcc-bugzi...@gcc.gnu.org>: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729 > > --- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> --- > On Wed, 8 Jun 2016, ysrumyan at gmail dot com wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729 >> >> --- Comment #23 from Yuri Rumyantsev <ysrumyan at gmail dot com> --- >> OK. I will try to prepare the second part of patch. >> Few comments about vect-simd-clone-5.c test failure. >> 1. This loop is marked with safelen=MAX_INT. >> 2. It contains the following stmt's: >> D.3301 = foo.simdclone.1 (vect_vec_iv_.25_12, 123, _17); >> # VUSE <.MEM_39> >> _22 = MEM[(vector(2) long long int[2] *)&D.3301]; >> # VUSE <.MEM_39> >> _23 = MEM[(vector(2) long long int[2] *)&D.3301 + 16B]; >> # .MEM_40 = VDEF <.MEM_39> >> D.3301 ={v} {CLOBBER}; >> vect__3.28_24 = VEC_PACK_TRUNC_EXPR <_22, _23>; >> and fuction ref_indep_Loop_p_1 checks that references >> MEM[(vector(2) long long int[2] *)&D.3301] >> and >> MEM[(vector(2) long long int[2] *)&D.3301 + 16B] >> are independent. >> We can avoid such bad behavior of safelen-check (1) put restriction that loop >> does not contain non-analyzed references; (2) add additional check that >> reference does not have operands defined inside loop (D.3301 in our case). >> >> What approach is more profitable for you? > > I think that we cannot use safelen() to disregard dependences > against "non-analyzed" references. This is because of exactly > such case. In future we might want to make less references > "non-analyzed" and use the general alias oracle on them > (the LIM dependence analysis predates that). > > So - simply put the safelen() check after the check for non-analyzed > reference in the disambiguator. > > -- > You are receiving this mail because: > You reported the bug.
