testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

Tested mmix-knuth-mmixware (where all torture-variants of
gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
x86_64-pc-linux-gnu.  Also stepped through the test for native,
w/wo. RUN_FRACTION defined to see that it worked as intended.

You may wonder what about the "sibling" tests inline-mem-cmp-1.c and
inline-mem-cpy-cmp-1.c.  Well, they FAIL, but not because of
timeouts(!)  To be continued....

Ok to commit?

Or, other suggestions?

-- >8 --
The test inline-mem-cpy-1.c takes 16 minutes at -O0 for the mmix
simulator on a 3.5 year old laptop and thus always times out, despite
the x 2 timeout (i.e. 10 minutes), and times out at all optimization
levels.  For the included file (when run as gcc.dg/memcmp-1.c), the
execution time on the same host is 9 minutes 54 seconds, so just
within 10 minutes timeout limit.  Seems pragmatically best to reduce
the torture-test by a factor of about 10, but there's no obvious small
set of entities to scale down to get the intended effect, and
splitting up the test into several tests seem a bit too intrusive.

Instead, introduce pseudo-random machinery to skip all but each
RUN_FRACTION:th iteration, defaulting to no change when RUN_FRACTION
isn't defined.  Use 11 for RUN_FRACTION, assuming this prime will lead
to even distribution within nested iterations with loops looking like
(0, 1) : (0, 1).  Do this only for the main loop in
test_driver_memcmp; the "outermost" two levels of iterations.

With this, execution time for -O0 as above is down to 1 minute 32
seconds.

	* gcc.dg/torture/inline-mem-cpy-1.c: Pass -DRUN_FRACTION=11
	when testing in a simulator.
	* gcc.dg/memcmp-1.c [RUN_FRACTION]: Add machinery to run only
	for each RUN_FRACTION:th iteration.
	(main): Call initialize_skip_iteration_count.
	(test_driver_memcmp): Check SKIP_ITERATION for each iteration.
---
 gcc/testsuite/gcc.dg/memcmp-1.c               | 35 +++++++++++++++++++
 .../gcc.dg/torture/inline-mem-cpy-1.c         |  1 +
 2 files changed, 36 insertions(+)

On 1/1/24 20:22, Hans-Peter Nilsson wrote:
> Tested mmix-knuth-mmixware (where all torture-variants of
> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> x86_64-pc-linux-gnu.  Also stepped through the test for native,
> w/wo. RUN_FRACTION defined to see that it worked as intended.
> 
> You may wonder what about the "sibling" tests inline-mem-cmp-1.c and
> inline-mem-cpy-cmp-1.c.  Well, they FAIL, but not because of
> timeouts(!)  To be continued....
> 
> Ok to commit?
> 
> Or, other suggestions?
I'm pretty sure there's already a target selector for "simulator"  So 
you might be able to do this automagically with somethign like

dg-additional-options "-DRUN_FRACTION=11" { target { simulator } }"

Or something close to that.

jeff

On Tue, 2 Jan 2024, Jeff Law wrote:
> 
> On 1/1/24 20:22, Hans-Peter Nilsson wrote:
> > Tested mmix-knuth-mmixware (where all torture-variants of
> > gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> > x86_64-pc-linux-gnu.  Also stepped through the test for native,
> > w/wo. RUN_FRACTION defined to see that it worked as intended.
> > 
> > You may wonder what about the "sibling" tests inline-mem-cmp-1.c and
> > inline-mem-cpy-cmp-1.c.  Well, they FAIL, but not because of
> > timeouts(!)  To be continued....
> > 
> > Ok to commit?
> > 
> > Or, other suggestions?
> I'm pretty sure there's already a target selector for "simulator"  So you
> might be able to do this automagically with somethign like
> 
> dg-additional-options "-DRUN_FRACTION=11" { target { simulator } }"
> 
> Or something close to that.

Hm...  But that's exactly what the one-line patch to 
gcc.dg/torture/inline-mem-cpy-1.c looked like, last in the 
submitted commit.  I had to double-check my sent-mail folder 
that I didn't miss that part. :)

I'm mostly worried about the patch to gcc.dg/memcpy-1.c.
Does that mean all-ok?

brgds, H-P

Ping.  (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)

On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:

> Tested mmix-knuth-mmixware (where all torture-variants of
> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> x86_64-pc-linux-gnu.  Also stepped through the test for native,
> w/wo. RUN_FRACTION defined to see that it worked as intended.
> 
> You may wonder what about the "sibling" tests inline-mem-cmp-1.c and
> inline-mem-cpy-cmp-1.c.  Well, they FAIL, but not because of
> timeouts(!)  To be continued....
> 
> Ok to commit?
> 
> Or, other suggestions?
> 
> -- >8 --
> The test inline-mem-cpy-1.c takes 16 minutes at -O0 for the mmix
> simulator on a 3.5 year old laptop and thus always times out, despite
> the x 2 timeout (i.e. 10 minutes), and times out at all optimization
> levels.  For the included file (when run as gcc.dg/memcmp-1.c), the
> execution time on the same host is 9 minutes 54 seconds, so just
> within 10 minutes timeout limit.  Seems pragmatically best to reduce
> the torture-test by a factor of about 10, but there's no obvious small
> set of entities to scale down to get the intended effect, and
> splitting up the test into several tests seem a bit too intrusive.
> 
> Instead, introduce pseudo-random machinery to skip all but each
> RUN_FRACTION:th iteration, defaulting to no change when RUN_FRACTION
> isn't defined.  Use 11 for RUN_FRACTION, assuming this prime will lead
> to even distribution within nested iterations with loops looking like
> (0, 1) : (0, 1).  Do this only for the main loop in
> test_driver_memcmp; the "outermost" two levels of iterations.
> 
> With this, execution time for -O0 as above is down to 1 minute 32
> seconds.
> 
> 	* gcc.dg/torture/inline-mem-cpy-1.c: Pass -DRUN_FRACTION=11
> 	when testing in a simulator.
> 	* gcc.dg/memcmp-1.c [RUN_FRACTION]: Add machinery to run only
> 	for each RUN_FRACTION:th iteration.
> 	(main): Call initialize_skip_iteration_count.
> 	(test_driver_memcmp): Check SKIP_ITERATION for each iteration.
> ---
>  gcc/testsuite/gcc.dg/memcmp-1.c               | 35 +++++++++++++++++++
>  .../gcc.dg/torture/inline-mem-cpy-1.c         |  1 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.dg/memcmp-1.c b/gcc/testsuite/gcc.dg/memcmp-1.c
> index ea837ca0f577..13ef5b3380d0 100644
> --- a/gcc/testsuite/gcc.dg/memcmp-1.c
> +++ b/gcc/testsuite/gcc.dg/memcmp-1.c
> @@ -34,6 +34,36 @@ int lib_strncmp(const char *a, const char *b, size_t n)
>  
>  #define MAX_SZ 600
>  
> +/* A means to run only a fraction of the tests, beginning at a random
> +   count.  */
> +#ifdef RUN_FRACTION
> +
> +#define SKIP_ITERATION skip_iteration ()
> +static unsigned int iteration_count;
> +
> +static _Bool
> +skip_iteration (void)
> +{
> +  _Bool run = ++iteration_count == RUN_FRACTION;
> +
> +  if (run)
> +    iteration_count = 0;
> +
> +  return !run;
> +}
> +
> +static void
> +initialize_skip_iteration_count ()
> +{
> +  srand (2024);
> +  iteration_count = (unsigned int) (rand ()) % RUN_FRACTION;
> +}
> +
> +#else
> +#define SKIP_ITERATION 0
> +#define initialize_skip_iteration_count()
> +#endif
> +
>  #define DEF_RS(ALIGN)                                                      \
>  static void test_memcmp_runtime_size_ ## ALIGN (const char *str1, 	   \
>  						const char *str2,	   \
> @@ -110,6 +140,8 @@ static void test_driver_memcmp (void (test_memcmp)(const char *, const char *, i
>    int i,j,l;
>    for(l=0;l<sz;l++) {
>      for(i=0;i<NRAND/sz;i++) {
> +      if (SKIP_ITERATION)
> +	continue;
>        for(j=0;j<l;j++) {
>  	buf1[j] = rand() & 0xff;
>  	buf2[j] = buf1[j];
> @@ -128,6 +160,8 @@ static void test_driver_memcmp (void (test_memcmp)(const char *, const char *, i
>    for(diff_pos = ((test_sz>TZONE)?(test_sz-TZONE):0); diff_pos < test_sz+TZONE; diff_pos++)
>      for(zero_pos = ((test_sz>TZONE)?(test_sz-TZONE):0); zero_pos < test_sz+TZONE; zero_pos++)
>        {
> +	if (SKIP_ITERATION)
> +	  continue;
>  	memset(buf1, 'A', 2*test_sz);
>  	memset(buf2, 'A', 2*test_sz);
>  	buf2[diff_pos] = 'B';
> @@ -490,6 +524,7 @@ DEF_TEST(49,1)
>  int
>  main(int argc, char **argv)
>  {
> +  initialize_skip_iteration_count ();
>  #ifdef TEST_ALL
>      RUN_TEST(1,1)
>      RUN_TEST(1,2)
> diff --git a/gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c b/gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c
> index f4952554dd01..f0752349571b 100644
> --- a/gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c
> +++ b/gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c
> @@ -1,5 +1,6 @@
>  /* { dg-do run } */
>  /* { dg-options "-finline-stringops=memcpy -save-temps -g0 -fno-lto" } */
> +/* { dg-additional-options "-DRUN_FRACTION=11" { target simulator } } */
>  /* { dg-timeout-factor 2 } */
>  
>  #include "../memcmp-1.c"
> -- 
> 2.30.2
> 
>

On Jan 12, 2024, at 2:52 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> 
> Ping.  (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)
> 
> On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:
> 
>> Tested mmix-knuth-mmixware (where all torture-variants of
>> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
>> x86_64-pc-linux-gnu.  Also stepped through the test for native,
>> w/wo. RUN_FRACTION defined to see that it worked as intended.
>> 
>> You may wonder what about the "sibling" tests inline-mem-cmp-1.c and
>> inline-mem-cpy-cmp-1.c.  Well, they FAIL, but not because of
>> timeouts(!)  To be continued....
>> 
>> Ok to commit?

Ok.

On 1/2/24 14:07, Hans-Peter Nilsson wrote:
> On Tue, 2 Jan 2024, Jeff Law wrote:
>>
>> On 1/1/24 20:22, Hans-Peter Nilsson wrote:
>>> Tested mmix-knuth-mmixware (where all torture-variants of
>>> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
>>> x86_64-pc-linux-gnu.  Also stepped through the test for native,
>>> w/wo. RUN_FRACTION defined to see that it worked as intended.
>>>
>>> You may wonder what about the "sibling" tests inline-mem-cmp-1.c and
>>> inline-mem-cpy-cmp-1.c.  Well, they FAIL, but not because of
>>> timeouts(!)  To be continued....
>>>
>>> Ok to commit?
>>>
>>> Or, other suggestions?
>> I'm pretty sure there's already a target selector for "simulator"  So you
>> might be able to do this automagically with somethign like
>>
>> dg-additional-options "-DRUN_FRACTION=11" { target { simulator } }"
>>
>> Or something close to that.
> 
> Hm...  But that's exactly what the one-line patch to
> gcc.dg/torture/inline-mem-cpy-1.c looked like, last in the
> submitted commit.  I had to double-check my sent-mail folder
> that I didn't miss that part. :)
> 
> I'm mostly worried about the patch to gcc.dg/memcpy-1.c.
> Does that mean all-ok?
Yea, sorry.  Not sure why it didn't register in my brain.

Yes, this was all OK.
jeff