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
