http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glisse at gcc dot gnu.org
--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
Discussing PR 53082 here since it was closed as a dup. It asks for 2 things:
1) Replacing a=malloc(n);b=malloc(m); ... free(a);free(b); with a single
malloc-free pair: a=malloc(n+m);b=a+n; ... free(a);.
2) Replacing some malloc calls with alloca.
I am wondering about the circumstances where those things are safe to do. The
second one can only be safe if the size is a constant or VRP tells us it is at
most a small constant. And then for both, nothing too weird must happen in
between, but I am not sure what bad things are possible exactly. The "easy"
case would be with the 2 malloc calls consecutive (what can't we put in
between?), the 2 free calls consecutive, everything in a single basic block
(this sounds way too restrictive), the argument of free an SSA_NAME defined
with the malloc call, nothing that may throw (or any other way we can avoid
coming back to execute free) in "...". Then I have a hard time finding bad
cases (except that on error, malloc returns 0, and we put 0+n in b, maybe it
requires a -fmalloc-cannot-fail). Are there other places in the compiler with a
similar set of checks?
And then we would also need to extend everything to new/delete :-(
(unless maybe we install an LTO version of libstdc++ and, with -fwhole-program
(taken as a promise not to LD_PRELOAD another new/delete), gcc accepts to
inline new/delete and sees malloc and free, but that seems a long shot...)
