This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 199/236] Introduce rtx_insn_list subclass of rtx_def


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]