From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23850 invoked by alias); 30 Aug 2014 06:24:38 -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 23841 invoked by uid 89); 30 Aug 2014 06:24:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 30 Aug 2014 06:24:36 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7U6OXbA008954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 30 Aug 2014 02:24:34 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-40.phx2.redhat.com [10.3.113.40]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7U6OWON020029; Sat, 30 Aug 2014 02:24:32 -0400 Message-ID: <54016E20.8080100@redhat.com> Date: Sat, 30 Aug 2014 06:24:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: David Malcolm , Trevor Saunders CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 199/236] Introduce rtx_insn_list subclass of rtx_def References: <1407345815-14551-1-git-send-email-dmalcolm@redhat.com> <1407345815-14551-200-git-send-email-dmalcolm@redhat.com> <20140807012924.GA10077@tsaunders-iceball.corp.tor1.mozilla.com> <1407425597.28418.58.camel@surprise> In-Reply-To: <1407425597.28418.58.camel@surprise> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg02685.txt.bz2 On 08/07/14 09:33, David Malcolm wrote: > On Wed, 2014-08-06 at 21:29 -0400, Trevor Saunders wrote: >> On Wed, Aug 06, 2014 at 01:22:58PM -0400, David Malcolm wrote: >>> +class GTY(()) rtx_insn_list : public rtx_def >>> +{ >>> + /* No extra fields, but adds invariant: (GET_CODE (X) == INSN_LIST). >> >> some nice future work would be to see if these can stop being rtxen at >> all and just have a insn and next pointer. > > Or some other data structures; see > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00825.html > for an example I tried. [I don't know if it's a *good* example > though :) ] I the case of forced_labels, I believe the only things we ever do are prepend to the list and iterate over the list performing some action on each item in the list. Order on the list doesn't matter IIRC, nor do we ever do something like "give me element 3 in the list" or "find this element in the list" Thus from an efficiency standpoint I don't see a big win for either vec or EXPR_LIST over the other. vec is probably better for iterating and access, but loses when we have to reallocate/copy the vector when we add elements to it. Space efficiency is probably better for vec. Where I think vec shines anyone with a basic background in standard C++ libraries is going to know what a vector is (or a forward_list if folks really didn't want to go with a vec implementation). Old farts such as myself "just know" that EXPR_LIST is a forward list implemented using rtx nodes with the implied properties noted above. However, it's not something a "newbie" is going to just know -- thus they're going to have to dig a bit to come to those conclusions. Changing to a vec or forward_list makes things clearer to someone casually reading the code and also carries to the reader some of those implied properties. And *that* is the reason why I think changing EXPR_LIST and INSN_LIST to be standard containers is a good move. The change for forced_labels looks quite reasonable to me and I'd look favorably upon submitting that as an RFA once the bootstrap and testing is done. jeff