I think only thing you're missing is that we probably don't want to be
using alloca in new code anyway. And if we're going through the trouble
of fixing old code, we ought to just remove alloca. So building up this
kind of class is probably taking folks in the wrong direction.
After spending some time combing over all alloca uses in the compiler, I
am very much inclined to agree :).
Pedro's comments up-thread ring true as well. Most of the alloca uses
in the compiler are actually ad-hoc allocation for a string that will be
quickly discarded or passed to get_identifier(). Very few, if any are
actually on a critical path. Most uses are things like building
diagnostics.
However, there are a few potentially problematic ones like alloca()ing
chunks of memory while processing GIMPLE_ASM (chunk * noutputs). This
may require something more efficient than malloc(). Though I really
wonder how prevalent inline asms are in that it would affect performance
in any measurable way if we replaced these with malloc or GCC's
auto_vec<> (which also uses malloc (or GGC) BTW).
After looking at all this code, I realize no size will fit all if we
want something clean. So, I take my approach back. I think we're best
served by a couple different approaches, depending on usage.
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?).
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.
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.
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...
