On 11/10/20 7:42 PM, Kewen.Lin via Gcc-patches wrote: > Hi Richard, > > Thanks for the review! > > on 2020/11/10 涓嬪崍7:31, Richard Sandiford wrote: >> "Kewen.Lin" <li...@linux.ibm.com> writes: >>> Hi, >>> >>> As Lyon pointed out, the newly introduced test case >>> gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf. >>> Loop vectorizer is able to vectorize the two loops which >>> operate on array tmp with load_lanes feature support. It >>> makes dse3 get unexpected inputs and do nothing. >>> >>> This patch is to teach the case to respect vect_load_lanes, >>> meanwhile to guard the check only under vect_int. >> I'm not sure this is the right check. The test passes on aarch64, >> which also has load lanes, but apparently doesn't use them for this >> test. I think the way the loop vectoriser handles the loops will >> depend a lot on target costs, which can vary in unpredictable ways. >> > You are right, although aarch64 doesn't have this failure, it can fail > with explicit -march=armv8-a+sve. It can vary as target features/costs > change. The check is still fragile. > > Your suggestion with -ftree-slp-vectorize below is better! > >> Does it work if you instead change -ftree-vectorize to -ftree-slp-vectorize? >> Or does that defeat the purpose of the test? > It works, nice, thanks for the suggestion! > > I appended one explicit -fno-tree-loop-vectorize to avoid it to fail > in case someone kicks off the testing with explicit -ftree-loop-vectorize. > > The updated version is pasted below, is it ok for trunk? > > BR, > Kewen > ----- > gcc/testsuite/ChangeLog: > > * gcc.dg/tree-ssa/pr96789.c: Adjusted by disabling loop vectorization.
OK jeff
