From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38422 invoked by alias); 1 Jul 2015 09:39:57 -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 38400 invoked by uid 89); 1 Jul 2015 09:39:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Jul 2015 09:39:55 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [23.233.68.71]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id D1A2AC06D; Wed, 1 Jul 2015 09:39:52 +0000 (UTC) Date: Wed, 01 Jul 2015 09:39:00 -0000 From: Trevor Saunders To: gcc-patches@gcc.gnu.org, Mikhail Maltsev , rdsandiford@googlemail.com Subject: Re: Add .def file for public target instructions Message-ID: <20150701093910.GB11111@tsaunders-iceball.corp.tor1.mozilla.com> References: <87ioaegtcp.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ioaegtcp.fsf@googlemail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg00015.txt.bz2 On Tue, Jun 23, 2015 at 07:41:42PM +0100, Richard Sandiford wrote: > [A fair bit later than promised, sorry...] > > Mikhail posted a patch to make genflags generate the default HAVE_foo > and gen_foo definitions that have recently been added to defaults.h: > > https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00723.html > > I agree it'd be a good idea to generate this kind of thing automatically, > but I think we should take the opportunity to move the interface to the > target structure. I.e.: > > HAVE_foo -> targetm.have_foo () > gen_foo -> targetm.gen_foo () > > This should move us closer to the pipedream goal of supporting multiple > targets at once. It should also mean that only the target code depends > on insn-flags.h. using targetm. certainly seems like an improvement. I wonder if it would be faster to stick this data on a per function object. I think that would mean you could compute what insns are available once when the function is created and afterwards all checks would only needed to be reading computed values. Trev