From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127921 invoked by alias); 19 Sep 2016 21:34:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 127906 invoked by uid 89); 19 Sep 2016 21:34:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=nightmare, our X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Sep 2016 21:34:50 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 13D83C05A28A for ; Mon, 19 Sep 2016 21:34:49 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-2.phx2.redhat.com [10.3.116.2]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8JLYmIT029164; Mon, 19 Sep 2016 17:34:48 -0400 Subject: Re: [PATCH 8/9] final.c selftests To: David Malcolm , gcc-patches@gcc.gnu.org References: <1473381053-18817-1-git-send-email-dmalcolm@redhat.com> <1473381053-18817-9-git-send-email-dmalcolm@redhat.com> <3fc5803f-050e-fe96-74bd-335fbe3c00e1@redhat.com> <1474061671.6782.106.camel@redhat.com> From: Jeff Law Message-ID: <2454e471-515a-5638-d3b7-1a7d97b738b9@redhat.com> Date: Mon, 19 Sep 2016 21:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1474061671.6782.106.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01229.txt.bz2 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