This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 199/236] Introduce rtx_insn_list subclass of rtx_def
- From: Jeff Law <law at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>, Trevor Saunders <tsaunders at mozilla dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 30 Aug 2014 00:24:32 -0600
- Subject: Re: [PATCH 199/236] Introduce rtx_insn_list subclass of rtx_def
- Authentication-results: sourceware.org; auth=none
- References: <1407345815-14551-1-git-send-email-dmalcolm at redhat dot com> <1407345815-14551-200-git-send-email-dmalcolm at redhat dot com> <20140807012924 dot GA10077 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <1407425597 dot 28418 dot 58 dot camel at surprise>
On 08/07/14 09:33, David Malcolm wrote:
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"
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
for an example I tried. [I don't know if it's a *good* example
though :) ]
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