On 06/08/20 06:16 +0100, Richard Sandiford wrote:
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 :-)
It really should be.
Artificial limitations like that are just a booby trap for the unwary.
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.
Yes, LLVM's SmallVector is very useful. You can achieve a similar
thing with a custom allocator in std::vector, but it's more cumbersome
and it alters the type from std::vector<X> to std::vector<X, Y>.
The beauty of the LLVM design is the common base class for
SmallVector<T, N> is the same for all N, so you can pass it to APIs
that don't care about the size and just work with the base interface.
(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
