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

[Jeff Law <law@redhat.com>]

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