[Some quote of mine] On Wed, Oct 22, 2014 at 10:37:02AM +0200, Jakub Jelinek wrote: > But it is the frontend that can know this, not the middle-end. > Having to compute the old size and using some intrinsic unconditionally > on all targets just because the code might be offloaded (and lowering that > after IPA to realloc proper (throwing away the unneeded argument) unless it is > nvptx target) would pessimize all the targets for a benefit of one. > What about any C/C++ code that needs realloc too?
Well, that's the reason I wrote in the next paragraph: > > Still and mainly for the benefit of (C/C++) code calling realloc > > directly, I concur with FX and Jakub that one should consider handling > > realloc later than in the front end. i.e. I think it is cleaner and it is required for manually calling realloc. Still, I wanted to rectify the assert that "in one case it seems like we can compute the old size" to * * * Thomas Schwinge wrote: > Jakub Jelinek wrote: > > As an optimization, if the compiler could prove that certain allocations are > > never realloced, never need aligned memory etc., you could optimize it to > > avoid the wrappers and use PTX "malloc"/"free" directly. > > I guess that if the compiler is able to prove that (no escaping pointers, > basically?), chances are that malloc/free can be eliminated completely? Well, one can also have: tmp = malloc(sizeof(a)) a = tmp; a = b; b = tmp; free(tmp) were one doesn't have realloc but there malloc/free cannot be eliminated. Tobias
