On 10/29/21 11:36, Richard Biener wrote:
On Tue, Oct 26, 2021 at 5:27 PM Martin Liška <mli...@suse.cz> wrote:
On 10/26/21 10:13, Richard Biener wrote:
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?
Hey.
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?
In the updated version of the patch I added:
/* { dg-final { scan-tree-dump-not "vectorized \[1-9\] loops" "vect" } } */
For others do we want to add XFAILs so we'll notice when we improve
on TSVC?
What type of XFAILs do you mean?
Like
/* { dg-final { scann-tree-dump "vectorized 1 loops" "vect" { xfail
*-*-* } } } */
All right. The only limitation with that I see is that we can vectorize
more loops in the future and this pattern is still going to xfail.
We won't notice, right?
when the testcase looks for vectorization but we don't do that (yet).
For s1113 for example you added a scan-tree-dump-not but the comment
suggests we'd expect vectorization.
The comment comes from the original source of TSVC. I copied entire functions.
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?
No, this is out of my scope, it has already taken me some time...
OK.
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?
All right, I'm adding also run-time checking. It took me some time making
array initialization for all tests independent. Plus I reduced number of
iterations to 1/10 of the origin. That makes tests quite fast.
What do you think about it now?
It looks nice now, but as said above some of the scan-tree-dump-not
should probably be xfailed scan-tree-dump, I was suggesting the
-not for the cases where vectorizing would be semantically wrong.
I see.
So I'd say OK with that change.
Installed that, thanks for review.
Martin
Thanks,
Richard.
Martin
Thanks,
Richard.
Thanks,
Martin
Richard.
