On Wed, Feb 05, 2025 at 04:12:38PM +0000, Andrew Carlotti wrote:
> Various aarch64 tests attempt to reduce the batch size for parallel test
> execution to a single test per batch, but it looks like the necessary
> changes to gcc_parallel_test_run_p were accidentally omitted when the
> aarch64-*-acle-asm.exp files were merged. This patch corrects that
> omission.
>
> This does have a measurable performance impact when running a limited
> number of tests. For example, in aarch64-sve-acle-asm.exp the use of
> torture options results in 16 compiler executions for each test; when
> running two such tests I observed a total test duration of 3m39 without
> this patch, and 1m55 with the patch. A full batch of 10 tests would
> have taken over 15 minutes to run on this machine.
I wonder if it wouldn't be better do the gcc_parallel_test_run_p
checks then per each torture option rather than once per test.
Anyway, I was worried about
> @@ -228,10 +231,10 @@ if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \
> }
>
> # Only test the filesystem every 10th iteration
> - incr gcc_runtest_parallelize_counter_minor
> - if { $gcc_runtest_parallelize_counter_minor == 10 } {
> + if { $gcc_runtest_parallelize_counter_minor >=
> $gcc_runtest_parallelize_limit_minor } {
> set gcc_runtest_parallelize_counter_minor 0
> }
> + incr gcc_runtest_parallelize_counter_minor
> if { $gcc_runtest_parallelize_counter_minor != 1 } {
changing behavior because before the change it was doing this if with
$gcc_runtest_parallelize_counter_minor in [0, 9] but newly without
aarch64*exp being involved it is in [1, 10]. Though, as the test
only cares about 1, I think it is ok. And we need to ensure that
when gcc_parallel_test_run_p is called the first time, this
if is always false, no matter what value $gcc_runtest_parallelize_limit_minor
has.
It might be clearer to change that test to
if { $gcc_runtest_parallelize_counter_minor != 0 } {
and do the incr after that rather than before (but then it would need
to be done on 2 paths rather than one).
> #verbose -log "gcc_parallel_test_run_p $testcase
> $gcc_runtest_parallelize_counter $gcc_runtest_parallelize_last"
> return $gcc_runtest_parallelize_last
So ok as is.
The reason for not the 10 value is e.g. testing on NFS or on AIX
where all filesystem touches might be awfully slow.
Jakub
