I was surprised by the always_inline trick. I suppose it makes
sense but I wouldn't have expected to be able to rely on it. Out
of curiosity I tested it with other compilers. It turns out that
it only works with some like GCC and IBM XLC++, but not others
like Clang or Sun CC. In recursive calls, they don't seem to
hold on to the memory allocated via alloca by the class ctor in
the caller.
Well, it was surprising to me as well, hence the comment. I expected it
to just work, and when it didn't I had to hunt in the inliner code to
find out why it was selectively inlining:
case GIMPLE_CALL:
/* Refuse to inline alloca call unless user explicitly forced so as
this may change program's memory overhead drastically when the
function using alloca is called in loop. In GCC present in
SPEC2000 inlining into schedule_block cause it to require 2GB of
RAM instead of 256MB. Don't do so for alloca calls emitted for
VLA objects as those can't cause unbounded growth (they're always
wrapped inside stack_save/stack_restore regions. */
As Richi pointed out, if the constructor doesn't get inlined (as you're
seeing in Clang and Sun CC), we could potentially clobber freed memory.
So much for that idea...
FWIW, rather than creating a new class around alloca and putting
effort into changing code to use it I think that investing time
into replacing the function's uses with an existing C++ container
class (either GCC's own or one from the STL) might be a better
way to go.
Yes, I suggested a combination of auto_vec<> (gcc's) and std::string
down thread.
Thanks for checking out the result from other compilers. Much appreciated.
Aldy
