On Mon, 11 Nov 2019, Andre Vieira (lists) wrote: > Hi, > > After during my investigation into the first testcase in PR92347 I noticed > that the ICE was arising because the vectorizer was under the assumption it > knew how to vectorize the zp call for both the main and epilogues. By the > time it got to transform the epilogue vectorizable_simd_clone_call would fail, > leading to the eventual ICE. The reason was because the main loop's safelen > was set to MAX_INT at time of analysis, but 0 for the epilogue at the time of > its transformation. This was because we were copying the loop's safelen to > the epilogue after vectorizing the main loop and we set safelen to 0 when we > are done vectorizing. This resulted in the epilogue always having safelen set > to 0 at transformation time. > > I believe its safe to assume that if the main loop can assume that it is safe > to vectorize between 0 and safelen then so is the epilogue in this context. > > Bootstrapped x86_64 and aarch64 and ran libgomp. > > Is this OK for trunk? (If approved can someone commit on my behalf as I'll be > away for two weeks?)
OK (and committed). Richard. > Cheers, > Andre > > gcc/ChangeLog: > 2019-11-11 Andre Vieira <andre.simoesdiasvie...@arm.com> > > * tree-vect-loop.c (vect_transform_loop): Don't overwrite epilogues > safelen with 0. > > gcc/testsuite/ChangeLog: > 2019-11-11 Andre Vieira <andre.simoesdiasvie...@arm.com> > > * gcc.dg/vect/pr92347.c: New test. > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)