On 2/21/21 4:12 AM, Peter Maydell wrote: > On Sat, 20 Feb 2021 at 21:29, Richard Henderson > <richard.hender...@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~