On Fri, Jun 7, 2019 at 5:08 PM Jason Merrill wrote: > > All expression statements and some other places express implicit conversion to > void with a CONVERT_EXPR. There's no reason to build up a new one as part of > constexpr evaluation. > > The ADDR_EXPR change also avoids a bit of garbage by discarding an ADDR_EXPR we > just built but didn't end up using. > > The location wrapper change doesn't affect garbage, it's just a minor > optimization. More constexpr garbage reduction: 1) Using a TREE_VEC instead of TREE_LIST to store bindings saves a bunch of space when dealing with multiple arguments. 2) We don't need to unshare any expressions containing a CONSTRUCTOR, or expressions within a CONSTRUCTOR; we're only interested in an initializer which is itself a CONSTRUCTOR, as that's what can get modified. A CONSTRUCTOR appearing as a subexpression won't be used to directly initialize a variable, so we don't need to unshare it. We also don't need to unshare the return value of the function, as it will be unshared if it is used as an initializer. 3) When we free the TREE_VEC for a call we end up not using, we can also free any CONSTRUCTORs we unshared for it. This unsharing isn't necessary, but oddly it significantly reduces the max resident memory on the testcase I've been looking at, so I'm going to leave it in. We also free CONSTRUCTORs for initialized parameters when we're done evaluating the function. Tested x86_64-pc-linux-gnu, applied to trunk.