public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@arm.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v3 15/16] [gdb/testsuite] sme: Add SVE/SME testcases
Date: Fri, 11 Aug 2023 16:42:26 +0100	[thread overview]
Message-ID: <26331934-4e54-5ed6-1c35-ed1c66262ba2@arm.com> (raw)
In-Reply-To: <87r0ojzkp4.fsf@linaro.org>

Hi,

On 8/4/23 01:59, Thiago Jung Bauermann wrote:
> 
> Luis Machado via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> diff --git a/gdb/testsuite/gdb.arch/aarch64-sme-core-0.exp b/gdb/testsuite/gdb.arch/aarch64-sme-core-0.exp
>> new file mode 100644
>> index 00000000000..c4755346bc8
>> --- /dev/null
>> +++ b/gdb/testsuite/gdb.arch/aarch64-sme-core-0.exp
>> @@ -0,0 +1,18 @@
>> +# Copyright 2023 Free Software Foundation, Inc.
>> +
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 3 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
>> +
>> +set id_start 0
>> +set id_end 24
> 
> It would be useful to have a comment mentioning that the range above
> tests the fpsimd state.
> 
> Same comment for the other aarch64-sme-*.exp tests.
> 

Yeah. That can be a bit obscure. I'll add some more documentation to that effect.

The current arrangement is mostly aiming at splitting these tests in a way that minimizes
the total run time.

I'm considering further splitting these, putting each test with SVL == 256 into its own
file. Those are the ones that take the longest to run. The others can be grouped.

Right now the split is based on continuous ranges (0~4, 5~9 etc). I may change that to a list
instead. That will allow us to clearly specify the tests we want for each sub-file, hopefully
causing each sub-test to have more or less the same run time.

>> +source $srcdir/$subdir/aarch64-sme-core.exp.tcl
> 
> <snip>
> 
>> +require is_aarch64_target
>> +
>> +if {![allow_aarch64_sve_tests]} {
>> +    verbose "Skipping ${gdb_test_file_name}."
>> +    return
>> +}
>> +
>> +if {![allow_aarch64_sme_tests]} {
>> +    verbose "Skipping ${gdb_test_file_name}."
>> +    return
>> +}
> 
> Can these "allow" tests also be invoked using "require"?
> This question applies for all aarch64-sme-*.exp.tcl files.
> 

Yes. When I started this code, we had not switched to this new format. Fixed now.

>> +
>> +test_sme_core_file $id_start $id_end
> 
> <snip>
> 
>> +#
>> +# Return the state string based on STATE
>> +#
>> +proc state_id_to_state_string { state } {
>> +  if {$state == 0} {
>> +    return "fpsimd"
>> +  } elseif {$state == 1} {
>> +    return "sve"
>> +  } elseif {$state == 2} {
>> +    return "ssve"
>> +  } elseif {$state == 3} {
>> +    return "za"
>> +  } elseif {$state == 4} {
>> +    return "za_ssve"
>> +  }
>> +}
>> +
>> +#
>> +# Given a test ID, return the string representing the register state.
>> +# The state is one of fpsimd, sve, ssve, za and za_ssve.
>> +#
>> +proc test_id_to_state { id } {
>> +  set state [expr $id / 25]
>> +
>> +  return [state_id_to_state_string $state]
>> +}
>> +
>> +#
>> +# Given a test ID, return the associated vector length.
>> +#
>> +proc test_id_to_vl { id } {
>> +  return [expr 16 << (($id / 5) % 5)]
>> +}
>> +
>> +#
>> +# Given a test ID, return the associated streaming vector length.
>> +#
>> +proc test_id_to_svl { id } {
>> +  return [expr 16 << ($id % 5)]
>> +}
> 
> I suggest adding an sme_ prefix to the procedures above, since "id" here
> is specific to SME testcases.
> 

See below.

>> +#
>> +# With register STATE, vector length VL and streaming vector length SVL,
>> +# run some register state checks to make sure the values are the expected
>> +# ones
>> +#
>> +proc check_state { state vl svl } {
>> +    # The FPSIMD registers are initialized with a value of 0x55 (85)
>> +    # for each byte.
>> +    #
>> +    # The SVE registers are initialized with a value of 0xff (255) for each
>> +    # byte, including the predicate registers and FFR.
>> +    #
>> +    # The SME (ZA) register is initialized with a value of 0xaa (170) for
>> +    # each byte.
>> +
>> +    # Check VG to make sure it is correct
>> +    set expected_vg [expr $vl / 8]
>> +    # If streaming mode is enabled, then vg is actually svg.
>> +    if {$state == "ssve" || $state == "za_ssve"} {
>> +	set expected_vg [expr $svl / 8]
>> +    }
>> +    gdb_test "print \$vg" " = ${expected_vg}"
>> +
>> +    # Check SVG to make sure it is correct
>> +    set expected_svg [expr $svl / 8]
>> +    gdb_test "print \$svg" " = ${expected_svg}"
>> +
>> +    # Check the value of SVCR.
>> +    gdb_test "print \$svcr" [get_svcr_value $state]
>> +
>> +    # When we have any SVE or SSVE state, the FPSIMD registers will have
>> +    # the same values as the SVE/SSVE Z registers.
>> +    set fpsimd_byte 85
>> +    if {$state == "sve" || $state == "ssve" || $state == "za_ssve"} {
>> +	set fpsimd_byte 255
>> +    }
>> +
>> +    set sve_byte 255
>> +    if {$state == "fpsimd" || $state == "za"} {
>> +	set sve_byte 85
>> +    }
>> +
>> +    # Check FPSIMD registers
>> +    check_fpsimd_regs $fpsimd_byte $state $vl $svl
>> +    # Check SVE registers
>> +    check_sve_regs $sve_byte $state $vl $svl
>> +    # Check SME registers
>> +    check_sme_regs 170 $state $svl
>> +}
> 
> Also here, perhaps call this function "check_sme_state"?
> 

Maybe. Instead of renaming these functions, how about renaming the helper .exp file
from aarch64.exp to aarch64-sme.exp? Or maybe split it into a sme-specific part and
a generic part.

Moving forward, I'd like to make these tests cover SVE as well. In that case, we would be
able to reuse some of these functions to raise the coverage of tests.

What do you think?

>> +# Run a test on the target to see if it supports Aarch64 SME extensions.
>> +# Return 0 if so, 1 if it does not.  Note this causes a restart of GDB.
>> +
>> +gdb_caching_proc allow_aarch64_sme_tests {} {
>> +    global srcdir subdir gdb_prompt inferior_exited_re
>> +
>> +    set me "allow_aarch64_sme_tests"
>> +
>> +    if { ![is_aarch64_target]} {
>> +	return 0
>> +    }
>> +
>> +    set compile_flags "{additional_flags=-march=armv8-a+sme}"
>> +
>> +    # Compile a test program containing SVE instructions.
> 
> s/SVE/SME/
> 

Oops. Fixed now.

>> +    set src {
>> +	int main() {
>> +	    asm volatile ("smstart za");
>> +	    return 0;
>> +	}
>> +    }
>> +    if {![gdb_simple_compile $me $src executable $compile_flags]} {
> 
> 


  reply	other threads:[~2023-08-11 15:42 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-30 13:46 [PATCH v3 00/16] SME support for AArch64 gdb/gdbserver on Linux Luis Machado
2023-06-30 13:46 ` [PATCH v3 01/16] [gdb/aarch64] Fix register fetch/store order for native AArch64 Linux Luis Machado
2023-07-24 15:53   ` Thiago Jung Bauermann
2023-07-24 16:26     ` Luis Machado
2023-06-30 13:46 ` [PATCH v3 02/16] [gdb/aarch64] refactor: Rename SVE-specific files Luis Machado
2023-06-30 13:46 ` [PATCH v3 03/16] [gdb/gdbserver] refactor: Simplify SVE interface to read/write registers Luis Machado
2023-07-24 16:19   ` Thiago Jung Bauermann
2023-07-25  9:28     ` Luis Machado
2023-06-30 13:46 ` [PATCH v3 04/16] [gdb/aarch64] sve: Fix return command when using V registers in a SVE-enabled target Luis Machado
2023-06-30 13:46 ` [PATCH v3 05/16] [gdb/aarch64] sme: Enable SME registers and pseudo-registers Luis Machado
2023-07-26 20:01   ` Thiago Jung Bauermann
2023-07-27  9:01     ` Luis Machado
2023-07-28  1:19       ` Thiago Jung Bauermann
2023-06-30 13:46 ` [PATCH v3 06/16] [gdbserver/aarch64] refactor: Adjust expedited registers dynamically Luis Machado
2023-06-30 13:46 ` [PATCH v3 07/16] [gdbserver/aarch64] sme: Add support for SME Luis Machado
2023-07-27 19:41   ` Thiago Jung Bauermann
2023-06-30 13:46 ` [PATCH v3 08/16] [gdb/aarch64] sve: Fix signal frame z/v register restore Luis Machado
2023-07-27 21:52   ` Thiago Jung Bauermann
2023-07-31 12:22     ` Luis Machado
2023-06-30 13:46 ` [PATCH v3 09/16] [gdb/aarch64] sme: Signal frame support Luis Machado
2023-07-27 22:25   ` Thiago Jung Bauermann
2023-07-31 12:23     ` Luis Machado
2023-06-30 13:46 ` [PATCH v3 10/16] [gdb/aarch64] sme: Fixup sigframe gdbarch when vg/svg changes Luis Machado
2023-07-28  1:01   ` Thiago Jung Bauermann
2023-07-31 12:27     ` Luis Machado
2023-06-30 13:46 ` [PATCH v3 11/16] [gdb/aarch64] sme: Support TPIDR2 signal frame context Luis Machado
2023-06-30 13:46 ` [PATCH v3 12/16] [gdb/generic] corefile/bug: Use thread-specific gdbarch when dumping register state to core files Luis Machado
2023-06-30 13:46 ` [PATCH v3 13/16] [gdb/generic] corefile/bug: Fixup (gcore) core file target description reading order Luis Machado
2023-07-28  3:12   ` Thiago Jung Bauermann
2023-07-31 11:38     ` Luis Machado
2023-09-05  8:28     ` Luis Machado
2023-06-30 13:46 ` [PATCH v3 14/16] [gdb/aarch64] sme: Core file support for Linux Luis Machado
2023-08-03  0:18   ` Thiago Jung Bauermann
2023-08-03 11:37     ` Luis Machado
2023-08-04 20:45       ` Thiago Jung Bauermann
2023-06-30 13:46 ` [PATCH v3 15/16] [gdb/testsuite] sme: Add SVE/SME testcases Luis Machado
2023-08-04  0:59   ` Thiago Jung Bauermann
2023-08-11 15:42     ` Luis Machado [this message]
2023-08-12  0:42       ` Thiago Jung Bauermann
2023-06-30 13:46 ` [PATCH v3 16/16] [gdb/docs] sme: Document SME registers and features Luis Machado
2023-07-01  8:58   ` Eli Zaretskii
2023-07-03  9:52     ` Luis Machado
2023-07-03 12:03       ` Eli Zaretskii
2023-07-03 12:06         ` Luis Machado
2023-07-17 11:40 ` [PING][PATCH v3 00/16] SME support for AArch64 gdb/gdbserver on Linux Luis Machado
2023-07-24  8:15 ` Luis Machado
2023-08-04 21:24 ` [PATCH " Thiago Jung Bauermann

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=26331934-4e54-5ed6-1c35-ed1c66262ba2@arm.com \
    --to=luis.machado@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    /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).