Fixed in r209530.
On Wed, May 21, 2014 at 6:24 PM, Jordan Rose <[email protected]> wrote: > > On May 21, 2014, at 9:22 , Manuel Klimek <[email protected]> wrote: > > On Wed, May 21, 2014 at 6:20 PM, Jordan Rose <[email protected]>wrote: > >> >> On May 21, 2014, at 9:19 , Manuel Klimek <[email protected]> wrote: >> >> On Wed, May 21, 2014 at 6:10 PM, Jordan Rose <[email protected]>wrote: >> >>> You might want to bump up the size of the SmallVector too. Right now >>> you're dynamically allocating a SmallVector<T, 1>, and immediately putting >>> two things into it. Alternately, you could use a std::vector, which has a >>> smaller sizeof itself. >>> >> >> I tried the various combinations, and it didn't make a difference, so I >> went for making the code the simplest, which was reusing the ParentVector >> typedef. >> If we change the ParentVector to a SmallVector<T, 2> we'll also use that >> for getParents() which mostly returns a single element. >> >> >> >> SmallVector's already too big to fit in registers, so adding another two >> words to it won't really hurt any uses on the stack, will it? >> > > So you're proposing to just bump it to 2? I'm happy to do that, but I lack > any way to get data that would sway me one way or the other, thus I think > it's mostly guesswork (but I trust your guesswork is probably better than > mine ;) > > > Well, we don't have that many matcher-based tools, so I'm not that > familiar with how ParentVector is really used in practice. Dynamically > allocating a SmallVector that is known to be too small just felt wrong to > me, is all. > > Jordan > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
