Andrew MacLeod via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: >> On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor <mjam...@suse.cz> >> wrote: >>> On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote: >>> [...] >>> >>>> * ipa-cp changes from vec<value_range> to std::vec<value_range>. >>>> >>>> We are using std::vec to ensure constructors are run, which they >>> aren't >>>> in our internal vec<> implementation. Although we usually steer away >>>> from using std::vec because of interactions with our GC system, >>>> ipcp_param_lattices is only live within the pass and allocated with >>> calloc. >>> Ummm... I did not object but I will save the URL of this message in the >>> archive so that I can waive it in front of anyone complaining why I >>> don't use our internal vec's in IPA data structures. >>> >>> But it actually raises a broader question: was this supposed to be an >>> exception, allowed only not to complicate the irange patch further, or >>> will this be generally accepted thing to do when someone wants to have >>> a >>> vector of constructed items? >> It's definitely not what we want. You have to find another solution to this >> problem. >> >> Richard. >> > > Why isn't it what we want? > > This is a small vector local to the pass so it doesn't interfere with > our PITA GTY. > The class is pretty straightforward, but we do need a constructor to > initialize the pointer and the max-size field. There is no allocation > done per element, so a small number of elements have a couple of fields > initialized per element. We'd have to loop to do that anyway. > > GCC's vec<> does not provide he ability to run a constructor, std::vec > does.
I realise you weren't claiming otherwise, but: that could be fixed :-) > I quizzed some libstdc++ folks, and there has been a lot of > optimizations done on std::vec over the last few years,.. They think its > pretty good now, and we were encouraged to use it. > > We can visit the question tho... What is the rationale for not using > std::vec in the compiler? We currently use std::swap, std:pair, > std::map, std::sort, and a few others. > is there some aspect of using std::vec I am not aware of that makes it > something we need to avoid? One reason to prefer vec<> for general interfaces is that it works with auto_vec<…, N>, making it possible to pre-allocate a reasonably-sized buffer on the stack without needing a round-trip through the allocators. FWIW, that isn't simply a GCC thing. LLVM (which is obviously much more C++-intensive than GCC) still makes heavy use of SmallVector for automatic variables. And the reason we have things like memory_block.h is that malloc did used to show up high in profiles. (FWIW, I'm not saying that's an argument in favour of avoiding std::vector completely. It's just a reason why it might not always be the right choice.) Thanks, Richard
