From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62593 invoked by alias); 12 Sep 2016 14:10:19 -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 62577 invoked by uid 89); 12 Sep 2016 14:10:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Especially, deeply, ugly, fear 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, 12 Sep 2016 14:10:17 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 75A3A445DA for ; Mon, 12 Sep 2016 14:10:16 +0000 (UTC) Received: from localhost.localdomain (vpn1-5-111.ams2.redhat.com [10.36.5.111]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CEAFXx016727; Mon, 12 Sep 2016 10:10:15 -0400 Subject: Re: [PATCH 0/9] RFC: selftests based on RTL dumps To: David Malcolm , gcc-patches@gcc.gnu.org References: <1473381053-18817-1-git-send-email-dmalcolm@redhat.com> From: Bernd Schmidt Message-ID: <319e562e-7b25-9e9d-eced-1ea4b7c2f109@redhat.com> Date: Mon, 12 Sep 2016 14:14: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: <1473381053-18817-1-git-send-email-dmalcolm@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00628.txt.bz2 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