std:vec for classes with constructor? (Was: Re: [patch] multi-range implementation for value_range (irange))

Andrew MacLeod amacleod@redhat.com
Thu Aug 6 01:07:52 GMT 2020


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 <mjambor@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 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?

Andrew







More information about the Gcc-patches mailing list