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] |
Hello, this patch makes CONSTRUCTOR use internally a VEC to store the elements being built, instead of using TREE_LIST. The patch survives a C-only bootstrap and most of the testsuite (a few regressions left). I decided to post it to gather some feedback since it's the first use of VEC in a tree, so people may object to the general principle or to how the VEC is exposed to CONSTRUCTOR's users. This is how the data structure looks like: + /* A single element of a CONSTRUCTOR. VALUE holds the actual value of the + element. INDEX can optionally design the position of VALUE: in arrays, + it is the index where VALUE has to be placed; in structures, it is the + FIELD_DECL of the member. */ + typedef struct constructor_elt_d GTY(()) + { + tree index; + tree value; + } constructor_elt; + + DEF_VEC_O(constructor_elt); + DEF_VEC_ALLOC_O(constructor_elt,gc); + + struct tree_constructor GTY(()) + { + struct tree_common common; + VEC(constructor_elt,gc) *elts; + }; As you can see, I made CONSTRUCTOR not to be an EXPR anymore, but I am not sure it is a good idea. Surely it saves a little memory in the structure, but probably it is not worth going through the regressions chasing out all the occurrences of IS_EXPR_CODE_CLASS / EXPR_P that need to be relaxed to handle CONSTRUCTOR. But after all, it would be an EXPR without operands, so it just did not look right. I appreciate any kind of feedback before I finish going through the regressions and changing all languages. Thanks, Giovanni Bajo
Attachment:
patch-constr.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |