On 09/16/2016 03:34 PM, David Malcolm wrote:
On Fri, 2016-09-16 at 14:45 -0600, Jeff Law wrote:
On 09/08/2016 06:30 PM, David Malcolm wrote:
gcc/ChangeLog:
        * final.c: Include selftest.h and selftest-rtl.h.
        (class selftest::temp_asm_out): New subclass of
        selftest::named_temp_file.
        (selftest::temp_asm_out::temp_asm_out): New ctor.
        (selftest::temp_asm_out::~temp_asm_out): New dtor.
        (class selftest::asm_out_test): New subclass of
        selftest::rtl_dump_test.
        (selftest::asm_out_test::asm_out_test): New ctor.
        (selftest::test_jump_insn): New function.
        (selftest::test_empty_function): New function.
        (selftest::test_asm_for_insn): New function.
        (TEST_ASM_FOR_INSN): New macro.
        (selftest::test_x86_64_leal): New function.
        (selftest::test_x86_64_negl): New function.
        (selftest::test_x86_64_cmpl): New function.
        (selftest::test_x86_64_cmovge): New function.
        (selftest::test_x86_64_ret): New function.
        (selftest::final_c_tests): New function.
        * selftest-run-tests.c (selftest::run_tests): Call
        selftest::final_c_tests.
        * selftest.h (selftest::final_c_tests): New decl.
I'm really not sure how useful these tests are going to be and would
question the long term maintenance costs of keeping them up-to-date.

I could see perhaps verifying that when there are multiple
alternatives
that the correct one is selected or somesuch, but these tests really
don't seem to be covering anything particularly useful.

My thinking here was that it might be useful to verify insn recognition
and output when someone is bringing up a new target, or adding new
insns to a .md file; the selftest::test_x86_64_cmpl show the beginnings
of how one might write that in selftest form.
Understood. I'm just not sure how helpful that will be in practice and it seems like a maintenance nightmare.

The case where I think something like this is useful is when there's multiple ways to express the same insn and there's a preferred form. Say because the preferred form is smaller, faster, whatever.

But even that can be incredibly painful. Consider zero-ing a register on the x86. There's mov 0,reg; xor reg, reg; sub reg,reg, etc. Which is preferred depends on the micro-architecture and possibly surrounding context, whether or not the containing block is hot or not, etc.



But I'm happy to drop it.
I don't think it buys us much right now. It is archived if we end up changing our minds.

jeff

Reply via email to