On 08/05/2016 03:37 PM, Aldy Hernandez wrote:
> My question is, how wed are we to an alloca based approach? Can we
> replace the non-critical uses by std::string (diagnostics,
> BLAH_check_failed(), building a string to manipulate the output of
> env("SOME_VAR"), etc?).
My suggestion too.
( I hope you'll pardon my sticking my nose into this. I'm hoping that
down the road gcc and gdb/binutils end up finding a common ground
for basic C++ utilities, and grow closer together. And you did say
you're fixing gdb's alloca problems as well. :-) )
> Then for things like the GCC driver wanting to create a vector of passed
> commands, we could use auto_vec<> (*gasp*, using a vector to represent a
> vector ;-)). Note that auto_vec<> uses malloc (or GC) but creating a
> malloc'd vector at startup is hardly on the fast path.
Note that that's why I specifically suggested auto_vec<char, MAX_ALLOCA_SIZE>
for critical-path things.
The second template parameter of auto_vec specifies the size of the
internal storage:
/* auto_vec is a subclass of vec that automatically manages creating and
releasing the internal vector. If N is non zero then it has N elements of
internal storage. The default is no internal storage, and you probably only
want to ask for internal storage for vectors on the stack because if the
size of the vector is larger than the internal storage that space is wasted.
*/
template<typename T, size_t N = 0>
class auto_vec : public vec<T, va_heap>
{
...
So for fast-path cases where you know off hand the usual scenario is "less
than N", you could use an auto_vec<sometype, N> variable on the stack. This
does not malloc unless you end up needing more than N. It actually ends up
being quite similar to your protected_alloca. E.g.,
yours:
protected_alloca chunk;
str = (char *) chunk.pointer ();
vs auto_vec:
typedef auto_vec<char, MAX_ALLOCA_SIZE> protected_alloca;
protected_alloca chunk;
str = chunk.address ();
(Of course a similar approach can be taken with other data
structures, stack -> set/map/hash, etc., but auto_vec is there
already, and vectors should be the default container.)
>
> For the remaining things we could use either alloca with a malloc
> fallback for trivial things like set_user_assembler_name() that only
> have one exit point, or take it on a case by case basis.
See above.
Thanks,
Pedro Alves
>
> But it seems to me that we can use an STL container for the non critical
> things (which are the majority of them), and something else (perhaps an
> RAII thinggie TBD later).
>
> Is this reasonable? I'd like to know before I spend any time converting
> anything to std::string and auto_vec<>.
>
> Thanks for everyone's input.
> Aldy
>
> p.s. Yeah yeah, both std::string and auto_vec<> malloc stuff and they're
> bloated, but do we care on non-critical things? We do get cleaner code
> as a result...
