public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: juzhe.zhong@rivai.ai
Cc: gcc-patches@gcc.gnu.org, kito.cheng@gmail.com,
	Jeff Law <jeffreyalaw@gmail.com>
Subject: Re: [PATCH] RISC-V: Add vm* mask C api tests
Date: Thu, 16 Feb 2023 10:38:03 +0100	[thread overview]
Message-ID: <Y+35e2qXHllGxC4o@tucnak> (raw)
In-Reply-To: <20230216033619.16472-1-juzhe.zhong@rivai.ai>

Hi!

I see in the past few weeks you've added huge amounts of these tests
du -shc *.target/riscv/*/
34M	gcc.target/riscv/rvv/
28M	g++.target/riscv/rvv/
61M	total
and new are coming (nothing at all at this year's start).
This is far larger than tests of any other architecture
(i386 has 35M total, aarch64 31M total, arm 17M total, powerpc 12M total,
everything else is even much smaller) but for the other architectures it has
been decades of testsuite coverage for features added over the years.
Rather than looking purely at size, I'm more worried about the content
of the tests.  Usually target testsuites include runtime tests whether
particular intrinsics etc. behave correctly at runtime, plus some compile
tests that they can be compiled with occassional scan-assembler* to mention
a particular instruction appears, but in these cases the scan-assembler*
covers the entire (albeit small) functions, which makes it IMHO a
maintainance nightmare whenever one wants to change something important
in the compiler.  Take e.g. the recent Andreas Schwab's change to make
-fasynchronous-unwind-tables the default on riscv, even that change required
quite a few changes.  My worry is that with these kind of tests changes like
that will become much harder and some people will simply decide not to do
such changes because having to adjust tens of thousands of tests even with
some scripting would be a nightmare.  Can't we do better than this?

E.g. what is the difference between gcc.target/riscv/rvv/ and
g++.target/riscv/rvv/ tests?  Are the <riscv_vector.h> APIs so different
between C and C++ that it needs to be tested twice?  Even if so,
we have the concept of c-c++-common tests, we could add c-c++-common.target
and make riscv.exp handle it similarly to how e.g. C and C++ dg.exp handles
those.  How do you create these tests?  If you use some generator for them,
wouldn't it be better to include the generator in the testsuite and generate
them on the fly?  We already have a precedent for that, e.g. the
gcc/testsuite/g*.dg/compat/struct-layout-1.exp testsuite has a generator
program written in C that creates tests on the fly.  Now, using something
like that would have 2 advantages, it would be much easier for maintainance,
if you do some global change in the compiler that affects those tests, just
adjust a few spots in the generator instead of tweaking currently 6000 tests
and counting.  Even if you aren't using a generator to write these tests
(that would be a lot of work then!), a question is if it couldn't be done by
one, have say some file like gcc has *.def files all around to describe what
you want to test and something that generates those.

Just wanted to chime in before we have 10 times more of such tests and it
will be too late to adjust...

On Thu, Feb 16, 2023 at 11:36:19AM +0800, juzhe.zhong@rivai.ai wrote:
> From: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
> 
> gcc/testsuite/ChangeLog:
> 
>         * gcc.target/riscv/rvv/base/vmand_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmand_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmand_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmandn_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmandn_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmandn_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmclr_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmclr_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmclr_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmmv_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmmv_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmmv_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmnand_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmnand_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmnand_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmnor_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmnor_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmnor_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmnot_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmnot_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmnot_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmor_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmor_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmor_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmorn_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmorn_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmorn_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmsbf_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmsbf_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmsbf_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmsbf_m_mu-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmsbf_m_mu-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmsbf_m_mu-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmset_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmset_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmset_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmsif_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmsif_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmsif_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmsif_m_mu-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmsif_m_mu-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmsif_m_mu-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmsof_m_m-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmsof_m_m-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmsof_m_m-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmsof_m_mu-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmsof_m_mu-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmsof_m_mu-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmxnor_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmxnor_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmxnor_mm-3.c: New test.
>         * gcc.target/riscv/rvv/base/vmxor_mm-1.c: New test.
>         * gcc.target/riscv/rvv/base/vmxor_mm-2.c: New test.
>         * gcc.target/riscv/rvv/base/vmxor_mm-3.c: New test.

	Jakub


  reply	other threads:[~2023-02-16  9:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16  3:36 juzhe.zhong
2023-02-16  9:38 ` Jakub Jelinek [this message]
2023-02-16  9:53   ` juzhe.zhong
2023-02-16 10:20     ` Jakub Jelinek
2023-02-16 10:31       ` juzhe.zhong
2023-02-16 13:10         ` Kito Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+35e2qXHllGxC4o@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).