I guess it has been a while since I've run aa32 risu on aa64 host.

The launchpad bug is something that should have been seen from the
beginning, but the similar aa64 operations are expanded as integer
code, not vector code.  The aa32 neon code has only recently been
converted to use gvecs.

The cmle0 (zero) bug has been exposed by the recent constant
propagation improvements; previously we saw a reg/reg compare.


r~


Richard Henderson (2):
  tcg/aarch64: Fix I3617_CMLE0
  tcg/aarch64: Fix generation of "scalar" vector operations

 tcg/aarch64/tcg-target.c.inc | 213 ++++++++++++++++++++++++++++++-----
 1 file changed, 182 insertions(+), 31 deletions(-)

-- 
2.25.1

On Sat, 20 Feb 2021 at 21:29, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> I guess it has been a while since I've run aa32 risu on aa64 host.
>
> The launchpad bug is something that should have been seen from the
> beginning, but the similar aa64 operations are expanded as integer
> code, not vector code.  The aa32 neon code has only recently been
> converted to use gvecs.
>
> The cmle0 (zero) bug has been exposed by the recent constant
> propagation improvements; previously we saw a reg/reg compare.

Idle thought: would it be possible to have a test framework that
exercised the TCG backend without being dependent on a particular
guest frontend?

thanks
-- PMM

On 2/21/21 4:12 AM, Peter Maydell wrote:
> On Sat, 20 Feb 2021 at 21:29, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> I guess it has been a while since I've run aa32 risu on aa64 host.
>>
>> The launchpad bug is something that should have been seen from the
>> beginning, but the similar aa64 operations are expanded as integer
>> code, not vector code.  The aa32 neon code has only recently been
>> converted to use gvecs.
>>
>> The cmle0 (zero) bug has been exposed by the recent constant
>> propagation improvements; previously we saw a reg/reg compare.
> 
> Idle thought: would it be possible to have a test framework that
> exercised the TCG backend without being dependent on a particular
> guest frontend?

*shrug* The question has been asked before.  It might be possible, but it's not
trivial.

In order to actually test something, there has to be enough board-level stuff
to do something.  Which means we have to at least define a virt board, the "tcg
guest" front end that can read the tcg input, etc.

It's not unlike gcc, for which similar "can we 'just' test rtl" questions were
mooted for years, to no effect.

What we haven't been doing with tcg, which did happen for gcc, is the regular
and consistent addition of regression tests. But even that runs afoul of the
fact that we've only got docker cross-compilers for x86_64.

Also, it'd be nice to actually run risu regularly, on all of the tcg hosts,
which I think is the main failure here.  We did all of the recent NEON testing
on x86_64 and (apparently) none at all on aarch64.


r~

Am 20.02.21 um 22:29 schrieb Richard Henderson:

> I guess it has been a while since I've run aa32 risu on aa64 host.
>
> The launchpad bug is something that should have been seen from the
> beginning, but the similar aa64 operations are expanded as integer
> code, not vector code.  The aa32 neon code has only recently been
> converted to use gvecs.
>
> The cmle0 (zero) bug has been exposed by the recent constant
> propagation improvements; previously we saw a reg/reg compare.
>
>
> r~
>
>
> Richard Henderson (2):
>    tcg/aarch64: Fix I3617_CMLE0
>    tcg/aarch64: Fix generation of "scalar" vector operations
>
>   tcg/aarch64/tcg-target.c.inc | 213 ++++++++++++++++++++++++++++++-----
>   1 file changed, 182 insertions(+), 31 deletions(-)


Thanks. This fixes https://bugs.launchpad.net/qemu/+bug/1916112.

Tested-by: Stefan Weil <sw@weilnetz.de>

Ping.

On 2/20/21 1:29 PM, Richard Henderson wrote:
> I guess it has been a while since I've run aa32 risu on aa64 host.
> 
> The launchpad bug is something that should have been seen from the
> beginning, but the similar aa64 operations are expanded as integer
> code, not vector code.  The aa32 neon code has only recently been
> converted to use gvecs.
> 
> The cmle0 (zero) bug has been exposed by the recent constant
> propagation improvements; previously we saw a reg/reg compare.
> 
> 
> r~
> 
> 
> Richard Henderson (2):
>    tcg/aarch64: Fix I3617_CMLE0
>    tcg/aarch64: Fix generation of "scalar" vector operations
> 
>   tcg/aarch64/tcg-target.c.inc | 213 ++++++++++++++++++++++++++++++-----
>   1 file changed, 182 insertions(+), 31 deletions(-)
>