On Tue, Oct 19, 2021 at 8:49 AM Martin Liška <mli...@suse.cz> wrote: > > On 10/18/21 12:08, Richard Biener wrote: > > Can you please use a subdirectory for the sources, a "toplevel" > > license.txt doesn't make much sense. You can simply amend > > vect.exp to process tsvc/*.c as well as sources so no need for an > > extra .exp file. > > Sure, it's a good idea and I've done that. > > > > > Is the license recognized as > > compatible to the GPL as far as source distribution is concerned? > > Yes: https://www.gnu.org/licenses/license-list.html#NCSA > > > > > Did you test the testcases on any non-x86 target? (power/aarch64/arm) > > Yes, I run the tests also on ppc64le-linux-gnu and aarch64-linux-gnu. > > Thoughts?
The overall setup looks fine to me. There are quite some testcases where there are no dg-final directives, some indicate in comments that we do not expect vectorization - for those do we want to add scan-tree-dump-not "loop vectorized" or so to make that clear? For others do we want to add XFAILs so we'll notice when we improve on TSVC? It looks like for example s124 is looking for IVOPTs rather than vectorization? There are testcases exercising float compares (s124 is an example), vectorizing those likely requires a subset of fast-math flags to allow if-conversion and masking, plus masking is not available on all targets. Is the intent to adjust testcase options accordingly? That said, I wonder whether it makes sense to initially only add the parts having dg-final directives (that PASS or XFAIL), just adding testcases for testing compile looks superfluous. All of the testcases are dg-do compile, but vectorizer testcases ideally would come with runtime verification. I assume the original TSVC provides this and as you include tscv.h in all tests I suppose including a runtime harness would be possible, no? Thanks, Richard. > Thanks, > Martin > > > > > Richard.
