public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Dmitry Selyutin <ghostmansd@gmail.com>
Cc: Luke Leighton <luke.leighton@gmail.com>,
	Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
	binutils@sourceware.org
Subject: Re: Are big tests allowed in binutils?
Date: Wed, 22 Jun 2022 08:55:50 +0200	[thread overview]
Message-ID: <e54bac62-75a1-934e-6454-daa02f5dde27@suse.com> (raw)
In-Reply-To: <CAMqzjet0r_H3wVr8XFbCi0DFtsUGanoykSemZsDUGX8yrmDVqw@mail.gmail.com>

On 21.06.2022 18:28, Dmitry Selyutin via Binutils wrote:
> The tests there are already generated with this assumption in mind
> already, they don't check all possible combinations (otherwise we'd
> have ended up with ~4GiB per test, eh).
> At the same time, they also check the operands together, basically
> this is a bunch of nested for loops, where each loop checks several
> predefined values for each operand.

This (in particular "nested loops") doesn't sound like it's matching
what Richard has suggested (which is a pattern I also generally try
to follow). Taking his example and assuming that I properly interpret
"several predefined values", your approach would result in

	FOO r0, r0
	FOO r0, r15
	FOO r15, r0
	FOO r15, r15

i.e. one more test than necessary. Obviously the number of "excess"
tests would grow (significantly) with the number of operands an insn
has (while there would be no difference for single-operand insns).

Jan

> I want to write some code which generates a test generator for
> binutils; this is the simplest option to avoid binutils depending on
> our code (you for sure don't want it).
> 
> This, however, is a big task, it requires many changes on our side,
> and I don't have time for this right now. It's also blocked somewhat
> with another task.
> Good news is that I will undoubtedly do it, because we have a plethora
> of scenarios which depend on auto-generation.
> And yes, we do want to be good citizens, that's why I brought up the
> whole auto-generation topic. :-)
> 


      reply	other threads:[~2022-06-22  6:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-17  5:11 Dmitry Selyutin
2022-06-17  6:19 ` Dmitry Selyutin
2022-06-20 10:42   ` Nick Alcock
2022-06-20 11:31     ` lkcl
2022-06-21 13:43       ` Nick Alcock
2022-06-21 17:26         ` lkcl
2022-06-21 17:29           ` Dmitry Selyutin
2022-06-21 19:23             ` lkcl
2022-06-17  9:14 ` Andreas Schwab
2022-06-21 15:32 ` Richard Earnshaw
2022-06-21 16:28   ` Dmitry Selyutin
2022-06-22  6:55     ` Jan Beulich [this message]

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=e54bac62-75a1-934e-6454-daa02f5dde27@suse.com \
    --to=jbeulich@suse.com \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=binutils@sourceware.org \
    --cc=ghostmansd@gmail.com \
    --cc=luke.leighton@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).