qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RISU PATCH 07/10] risugen: add --sve support


From: Dave Martin
Subject: Re: [Qemu-devel] [RISU PATCH 07/10] risugen: add --sve support
Date: Thu, 9 Nov 2017 12:21:51 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Nov 07, 2017 at 03:05:55PM +0000, Alex Bennée wrote:
> This is similar to the approach used by the FP/simd data in so far as
> we generate a block of random data and then load into it. As there are
> no post-index SVE operations we need to emit an additional incp
> instruction to generate our offset into the array.
> 
> Signed-off-by: Alex Bennée <address@hidden>
> ---
>  risugen        |  3 +++
>  risugen_arm.pm | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
>  2 files changed, 53 insertions(+), 7 deletions(-)
> 
> diff --git a/risugen b/risugen
> index aba4bb7..0ac8e86 100755
> --- a/risugen
> +++ b/risugen
> @@ -317,6 +317,7 @@ sub main()
>      my $condprob = 0;
>      my $fpscr = 0;
>      my $fp_enabled = 1;
> +    my $sve_enabled = 1;
>      my $big_endian = 0;
>      my ($infile, $outfile);
>  
> @@ -334,6 +335,7 @@ sub main()
>                  },
>                  "be" => sub { $big_endian = 1; },
>                  "no-fp" => sub { $fp_enabled = 0; },
> +                "sve" => sub { $sve_enabled = 1; },
>          ) or return 1;
>      # allow "--pattern re,re" and "--pattern re --pattern re"
>      @pattern_re = split(/,/,join(',',@pattern_re));
> @@ -361,6 +363,7 @@ sub main()
>          'fpscr' => $fpscr,
>          'numinsns' => $numinsns,
>          'fp_enabled' => $fp_enabled,
> +        'sve_enabled' => $sve_enabled,
>          'outfile' => $outfile,
>          'details' => \%insn_details,
>          'keys' => address@hidden,
> diff --git a/risugen_arm.pm b/risugen_arm.pm
> index 2f10d58..8d1e1fd 100644
> --- a/risugen_arm.pm
> +++ b/risugen_arm.pm
> @@ -472,9 +472,47 @@ sub write_random_aarch64_fpdata()
>      }
>  }
>  
> -sub write_random_aarch64_regdata($)
> +sub write_random_aarch64_svedata()
>  {
> -    my ($fp_enabled) = @_;
> +    # Load SVE registers
> +    my $align = 16;
> +    my $vl = 16;                             # number of vqs

Would this be better phrased

        my $vq = 16;                            # quadwords per vector

> +    my $datalen = (32 * $vl * 16) + $align;
> +
> +    write_pc_adr(0, (3 * 4) + ($align - 1)); # insn 1
> +    write_align_reg(0, $align);              # insn 2
> +    write_jump_fwd($datalen);                # insn 3
> +
> +    # align safety
> +    for (my $i = 0; $i < ($align / 4); $i++) {
> +        # align with nops
> +        insn32(0xd503201f);
> +    };
> +
> +    for (my $rt = 0; $rt <= 31; $rt++) {
> +        for (my $q = 0; $q < $vl; $q++) {
> +            write_random_fpreg_var(4); # quad
> +        }
> +    }
> +
> +    # Reset all the predicate registers to all true
> +    for (my $p = 0; $p < 16; $p++) {
> +        insn32(0x2518e3e0 | $p);
> +    }
> +
> +    # there is no post index load so we do this by hand
> +    write_mov_ri(1, 0);
> +    for (my $rt = 0; $rt <= 31; $rt++) {
> +        # ld1d    z0.d, p0/z, [x0, x1, lsl #3]
> +        insn32(0xa5e14000 | $rt);
> +        # incp    x1, p0.d
> +        insn32(0x25ec8801);

You could avoid this with the unpredicated form LDR (vector).
(LD1x scalar+immediate doesn't provide enough immediate range).

        # ldr   z$rt, [x0, #$rt, mul vl]
        insn32(0x85804000 + $rt + (($rt & 7) << 10) + (($rt & 0x18) << 13));

which is what the kernel does.

No harm in exercising different instructions though!  The kernel uses
embarrassingly few.


Does it matter that the stride will depend on the actual current VL?
If x0 just points to a block of random data, I guess it doesn't matter:
some trailing data remains unused, but that doesn't make the used data
any less random.

[...]

Cheers
---Dave



reply via email to

[Prev in Thread] Current Thread [Next in Thread]