[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about TCG backend correctness
From: |
Alex Bennée |
Subject: |
Re: Question about TCG backend correctness |
Date: |
Wed, 19 Oct 2022 14:46:01 +0100 |
User-agent: |
mu4e 1.9.1; emacs 28.2.50 |
LIU Zhiwei <zhiwei_liu@linux.alibaba.com> writes:
> On 2022/10/18 13:22, Richard Henderson wrote:
>
> On 10/18/22 01:27, LIU Zhiwei wrote:
>
> Maybe I can run RISU on qemu-aarch64(x86) and qemu-aarch64(risc-v) to check
> the RISC-V backend.
>
> This is a good start for debugging a tcg backend.
>
> After fixing some bugs, RISU can run some instructions now. Thanks.
>
> IMHO, the next 2 requests should be satisfied for TCG test.
>
> 1. Add a unit test case for any lower level and small function is easy.
>
> For example, the function in risc-v backend,
>
> static bool tcg_out_mov(TCGContext *s, TCGType type, TCGReg ret, TCGReg arg)
> {
> if (ret == arg) {
> return true;
> }
> switch (type) {
> case TCG_TYPE_I32:
> case TCG_TYPE_I64:
> tcg_out_opc_imm(s, OPC_ADDI, ret, arg, 0);
> break;
> default:
> g_assert_not_reached();
> }
> return true;
> }
>
> Write a unit test case for it is not easy currently. I don't know how to
> fill the TCGContext struct and other
> parameters.
> And there is no test framework where I can reuse.
>
> The others may say that we can run a lot of benchmark to ensure we have a
> good coverage and don't
> need such a low level test case. Some reasonable. But it will lead to a very
> high test burden and it is very hard to
> get
> a good coverage only through high level test.
You can at the very least use the gcov build to identify which bits of
the backend are not exercised by "check-tcg" and maybe write a few more
tests to fill it in. It's not a direct exercising of the code but it at
least ensures it has run and worked at least once.
>
> 2. Add a unit test case for any high level function is easy, such as
> tcg_gen_code.
>
> The check-tcg test belongs to the high level testing.
>
> Best Regards,
> Zhiwei
>
> It's not comprehensive, because RISU executes one instruction at a time then
> raises an exception to check the
> results. This means that the tcg optimizer doesn't have much to work with,
> which means that the tcg backend is not
> as stressed as it could be.
>
> I've long wanted to have the ability to have TCG unit tests where a
> virtual processor could be defined for the purpose of directly
> exercising TCG.
>
> We already have many ISAs as the front end of TCG. Will the virtual
> processor here be some
> different?
>
> It wouldn't. This is my argument against creating a new virtual processor.
>
> I do think we should be better about creating regression tests for bugs
> fixed, in the form of small focused assembly
> test cases which get run via check-tcg.
>
> r~
--
Alex Bennée