qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH 0/2] tcg/aarch64: Fixes to vector ops


From: Richard Henderson
Subject: Re: [PATCH 0/2] tcg/aarch64: Fixes to vector ops
Date: Sun, 21 Feb 2021 16:21:39 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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~



reply via email to

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