[Bug tree-optimization/19831] Missing DSE/malloc/free optimization

["glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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...)