Re: [PATCH 0/9] RFC: selftests based on RTL dumps

[Bernd Schmidt <bschmidt@redhat.com>]

In general, it's functionality that I would very much like to have 
(although maybe it's less useful these days now that the rtl side is 
fairly static). I think there's not much sense looking too deeply at the 
individual patches yet; we need to first figure out what we would really 
like this to look like in the end.

> These tests are very target-specific and were developed mostly for
> target==x86_64, and a little for target==aarch64.
> I put clauses like this in the various test functions, which is a kludge:
>
>     /* Only run these tests for i386.  */
>  #ifndef I386_OPTS_H
>     return;
>  #endif
>
> Is there a better way to express this condition?  (I guess I could
> add a selftest::target_is_x86_p () predicate).

My preferred solution would still be a separate selftest backend, which 
could be built as a cross-compiler once in a separate top-level 
directory. That way we have control over it, and maintainers of actual 
targets don't need to fear breaking selftests when they make changes to 
their ports. The downside would primarily be the time to build it.

> +  const char *input_dump
> +    = ("(insn 8 0 9 2 (set (reg:DI 78)\n"
> +       "        (lshiftrt:DI (reg:DI 76)\n"
> +       "            (const_int 32 [0x20])))\n"
> +       "        ../../src/gcc/testsuite/gcc.dg/asr_div1.c:14\n"
> +       "        641 {*aarch64_lshr_sisd_or_int_di3}\n"
> +       "     (expr_list:REG_DEAD (reg:DI 76)\n"
> +       "        (nil)))\n"
> +       "(insn 9 8 0 2 (set (reg:SI 79)\n"
> +       "        (ashiftrt:SI (subreg:SI (reg:DI 78) 0)\n"
> +       "            (const_int 3 [0x3])))\n"
> +       "        ../../src/gcc/testsuite/gcc.dg/asr_div1.c:14\n"
> +       "        642 {*aarch64_ashr_sisd_or_int_si3}\n"
> +       "     (expr_list:REG_DEAD (reg:DI 78)\n"
> +       "        (nil)))\n");

I can sort of see the desire to just copy&paste dumps into this, but 
this strikes me as really ugly. Especially if we end up using real 
targets this hard-codes not just pattern structure but also pattern 
names, which I think is too great a burden on target maintainers.

It's also not unheard of for the insn structure to change a bit; I 
remember a change which swapped location and pattern (I think).

There's also a fairly large amount of visual clutter here, such as the 
input filenames.

Maybe there's room for a tool to take input dumps and convert them to 
something more readable, or maybe to a sequence of gen_/emit_ function 
calls?


Bernd