On Tue, Apr 19, 2011 at 7:59 AM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > In the attached testcase, we treat: > > sum += x[i][0] * x[i][0] + x[i][1] * x[i][1]; > > as being two independent strided loads: x[i][0] and x[i][1]. > On targets with appropriate support, we therefore use two interleaved > loads rather than one, then discard one half of each result. > This does not happen if bar() is compiled on its own. > > The code before vectorisation looks like this: > > <bb 3>: > i.0_5 = (unsigned int) i_32; > D.3532_6 = i.0_5 * 320; > D.3533_8 = x_7(D) + D.3532_6; > > <bb 4>: > i.1_14 = (unsigned int) i_34; > D.3559_15 = i.1_14 * 8; > D.3558_16 = D.3533_8 + D.3559_15; > D.3557_17 = *D.3558_16[0]; > D.3555_19 = *D.3558_16[1]; > ... > > The two DR_BASE_ADDRESSES are therefore the expansion of D.3558_8: > > x_7(D) + (unsigned int) i_32 * 320 > > which we don't think are equal. The comment in tree-data-refs.h > made me think that (unsigned int) i_32 * 320 ought really to be > in the DR_OFFSET, but that only seems to apply to offsets that > occur in the memory reference itself. > > Fixed by using operand_equal_p to compare base addresses. > Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install? > > I've not made the test dependent on a target selector because > it seemed like the message should be printed regardless. > > Richard > > > gcc/ > * tree-vect-data-refs.c (vect_drs_dependent_in_basic_block): Use > operand_equal_p to compare DR_BASE_ADDRESSes. > (vect_check_interleaving): Likewise. >
This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366 -- H.J.
