Re: Implement removal of malloc/free pairs with NULL check

2024-11-13 Thread Richard Biener
On Wed, 6 Nov 2024, Jan Hubicka wrote: > Hi, > this is updated patch which adds -fmalloc-dce flag to control malloc/free > removal. I ended up copying what -fallocation-dse does so -fmalloc-dce=1 > enables malloc/free removal provided return value is unused otherwise and > -fmalloc-dce=2 allows a

Re: Implement removal of malloc/free pairs with NULL check

2024-11-12 Thread Jan Hubicka
> Hi, > this is updated patch which adds -fmalloc-dce flag to control malloc/free > removal. I ended up copying what -fallocation-dse does so -fmalloc-dce=1 > enables malloc/free removal provided return value is unused otherwise and > -fmalloc-dce=2 allows additional NULL pointer checks which it f

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Jan Hubicka
Hi, this is updated patch which adds -fmalloc-dce flag to control malloc/free removal. I ended up copying what -fallocation-dse does so -fmalloc-dce=1 enables malloc/free removal provided return value is unused otherwise and -fmalloc-dce=2 allows additional NULL pointer checks which it folds to no

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Jakub Jelinek
On Wed, Nov 06, 2024 at 01:08:11PM +0100, Jakub Jelinek wrote: > Though, unsure how that > https://eel.is/c++draft/expr.new#14 > interacts with > https://eel.is/c++draft/expr.new#8 > and we'd have to check if we do the size checking before the > ::operator new/new[] calls or it ::operator new just

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Alexander Monakov
On Wed, 6 Nov 2024, Richard Biener wrote: > Since we had malloc/free pair removal for quite some time I think > it should stay on by default. I missed that; now I see what you meant by "not making the existing situation worse". I still miss what happened to "correctness trumps performance" :)

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Richard Biener
On Wed, 6 Nov 2024, Alexander Monakov wrote: > > On Wed, 6 Nov 2024, Richard Biener wrote: > > > Since we had malloc/free pair removal for quite some time I think > > it should stay on by default. > > I missed that; now I see what you meant by "not making the existing > situation worse". > > I

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Jakub Jelinek
On Wed, Nov 06, 2024 at 02:44:12PM +0300, Alexander Monakov wrote: > I didn't see a discussion of a more gentle approach where instead of > replacing the result of malloc with a non-zero constant, we would change > > tmp = malloc(sz); > > to > > tmp = (void *)(sz <= SIZE_MAX / 2); > > and l

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Richard Biener
On Wed, 6 Nov 2024, Jan Hubicka wrote: > > > Thinking about this some more, I think we should just add -fno-malloc-dce > > > option and do it even if ranges don't guarantee it won't be half of AS or > > > more, that is really just a special case and not too different from > > > doing 3 PTRDIFF_MAX

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Jan Hubicka
> > Thinking about this some more, I think we should just add -fno-malloc-dce > > option and do it even if ranges don't guarantee it won't be half of AS or > > more, that is really just a special case and not too different from > > doing 3 PTRDIFF_MAX - 10 allocations and expecting at least one of

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Richard Biener
On Tue, 5 Nov 2024, Jakub Jelinek wrote: > On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote: > > > POSIX semantics for malloc involve errno. > > > > So if I can check errno to see if malloc failed, I guess even our > > current behaviour of optimizing away paired malloc+free calls provi

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Richard Biener
On Sat, 2 Nov 2024, Alexander Monakov wrote: > > On Sat, 2 Nov 2024, Sam James wrote: > > > Some references to feed discussion which I had in my logs from > > discussing it with someone the other week after that interaction we > > had with alanc: > > * https://github.com/llvm/llvm-project/issues

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Jakub Jelinek
On Wed, Nov 06, 2024 at 09:55:29AM +0100, Richard Biener wrote: > Btw, did you check what happens when doing new/delete without nothrow() > and either external or internal EH? I think optimizing is OK in all > cases, but I guess EH edges will prevent the optimization? I've checked the one with ex

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Andrew Pinski
On Wed, Nov 6, 2024 at 12:43 AM Sam James wrote: > > Sam James writes: > > > Alexander Monakov writes: > > > >> On Fri, 1 Nov 2024, Jan Hubicka wrote: > >> > >>> > I have a vague memory that one of the tests in SPEC has a loop that > >>> > tries to malloc, doubling the size each time, until it f

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Richard Biener
On Fri, 1 Nov 2024, Jan Hubicka wrote: > > On Fri, Nov 01, 2024 at 11:39:13AM +0100, Jan Hubicka wrote: > > > The testcase does: > > > /* { dg-additional-options "-O3 -fsanitize=undefined" } */ > > > > > > void memory_exhausted(); > > > void memcheck(void *ptr) { > > > if (ptr) /* { dg-warning

Re: Implement removal of malloc/free pairs with NULL check

2024-11-06 Thread Sam James
Sam James writes: > Alexander Monakov writes: > >> On Fri, 1 Nov 2024, Jan Hubicka wrote: >> >>> > I have a vague memory that one of the tests in SPEC has a loop that >>> > tries to malloc, doubling the size each time, until it fails. Would >>> > the patch change the behavior of such a loop? >>

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Sam James
Jan Hubicka writes: > [...] > The attached patch adds code to track size of allocated block and > disable the transformation when the block is not known to be smaller > then half of the address space by ranger. We can do the runtime check > discussed on the top of that. > > I have bootstrap®ress

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Alexander Monakov
On Tue, 5 Nov 2024, Jakub Jelinek wrote: > Anyway, IMHO just checking errno because you rely on malloc must have failed > in certain case is obscure. You'd better at least that that it actually > failed. I know, but obscurity or weirdness should be irrelevant when we are debating correctness.

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Jan Hubicka
> On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote: > > > POSIX semantics for malloc involve errno. > > > > So if I can check errno to see if malloc failed, I guess even our > > current behaviour of optimizing away paired malloc+free calls provided > > that the return value is unused is

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Jakub Jelinek
On Tue, Nov 05, 2024 at 08:15:04PM +0300, Alexander Monakov wrote: > > On Tue, 5 Nov 2024, Jakub Jelinek wrote: > > > On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote: > > > > POSIX semantics for malloc involve errno. > > > > > > So if I can check errno to see if malloc failed, I gues

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Alexander Monakov
On Tue, 5 Nov 2024, Jakub Jelinek wrote: > On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote: > > > POSIX semantics for malloc involve errno. > > > > So if I can check errno to see if malloc failed, I guess even our > > current behaviour of optimizing away paired malloc+free calls pro

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Jakub Jelinek
On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote: > > POSIX semantics for malloc involve errno. > > So if I can check errno to see if malloc failed, I guess even our > current behaviour of optimizing away paired malloc+free calls provided > that the return value is unused is problematic

Re: Implement removal of malloc/free pairs with NULL check

2024-11-05 Thread Jan Hubicka
> > On Sat, 2 Nov 2024, Sam James wrote: > > > Some references to feed discussion which I had in my logs from > > discussing it with someone the other week after that interaction we > > had with alanc: > > * https://github.com/llvm/llvm-project/issues/28790 (not very > > insightful, other than to

Re: Implement removal of malloc/free pairs with NULL check

2024-11-02 Thread Alexander Monakov
On Sat, 2 Nov 2024, Sam James wrote: > Some references to feed discussion which I had in my logs from > discussing it with someone the other week after that interaction we > had with alanc: > * https://github.com/llvm/llvm-project/issues/28790 (not very > insightful, other than to show it has a

Re: Implement removal of malloc/free pairs with NULL check

2024-11-02 Thread Martin Uecker
> > > > Please reconsider? Why to we need to match LLVM here?< > > Matching llvm is not really the goal. I implemented it since it is > useful optimization for code that builds small objects on heap and > compiler can optimize away their use. This is relatively common for > code with higer abstra

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Sam James
Alexander Monakov writes: > On Fri, 1 Nov 2024, Jan Hubicka wrote: > >> > I have a vague memory that one of the tests in SPEC has a loop that >> > tries to malloc, doubling the size each time, until it fails. Would >> > the patch change the behavior of such a loop? >> >> If the resulting alloca

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jakub Jelinek
On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote: > > > > malloc(SIZE_MAX / 2 + 1) does not succeed. > > Is malloc required to return NULL for block of half of address size or > it is glibc behavior? Some time ago we was discussing possibility to I don't see C23 saying that explicitly

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jakub Jelinek
On Fri, Nov 01, 2024 at 02:07:26PM +0100, Jan Hubicka wrote: > > On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote: > > > > > > > > malloc(SIZE_MAX / 2 + 1) does not succeed. > > > > > > Is malloc required to return NULL for block of half of address size or > > > it is glibc behavior? S

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jan Hubicka
> On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote: > > > > > > malloc(SIZE_MAX / 2 + 1) does not succeed. > > > > Is malloc required to return NULL for block of half of address size or > > it is glibc behavior? Some time ago we was discussing possibility to > > I don't see C23 saying

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jan Hubicka
> > On Fri, 1 Nov 2024, Jan Hubicka wrote: > > > > I have a vague memory that one of the tests in SPEC has a loop that > > > tries to malloc, doubling the size each time, until it fails. Would > > > the patch change the behavior of such a loop? > > > > If the resulting allocation is unused exce

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jan Hubicka
> On Fri, Nov 01, 2024 at 11:39:13AM +0100, Jan Hubicka wrote: > > The testcase does: > > /* { dg-additional-options "-O3 -fsanitize=undefined" } */ > > > > void memory_exhausted(); > > void memcheck(void *ptr) { > > if (ptr) /* { dg-warning "leak" } */ > > memory_exhausted(); > > } > > > >

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Alexander Monakov
On Fri, 1 Nov 2024, Jan Hubicka wrote: > > I have a vague memory that one of the tests in SPEC has a loop that > > tries to malloc, doubling the size each time, until it fails. Would > > the patch change the behavior of such a loop? > > If the resulting allocation is unused except for NULL che

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jakub Jelinek
On Fri, Nov 01, 2024 at 11:39:13AM +0100, Jan Hubicka wrote: > The testcase does: > /* { dg-additional-options "-O3 -fsanitize=undefined" } */ > > void memory_exhausted(); > void memcheck(void *ptr) { > if (ptr) /* { dg-warning "leak" } */ > memory_exhausted(); > } > > int emalloc(int size)

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jan Hubicka
> > I have a vague memory that one of the tests in SPEC has a loop that > tries to malloc, doubling the size each time, until it fails. Would > the patch change the behavior of such a loop? If the resulting allocation is unused except for NULL check we will make it always "succeed" and thus the

Re: Implement removal of malloc/free pairs with NULL check

2024-11-01 Thread Jan Hubicka
> > Very excited to see this and the other work -- thank you! > > I seem to get this when testing it out: > +Running gcc:/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ... > +FAIL: gcc.dg/analyzer/pr101837.c (test for warnings, line 10) > +FAIL: gcc.dg/analyzer/pr101837.c (test for warnings, line 5)

Re: Implement removal of malloc/free pairs with NULL check

2024-10-31 Thread Sam James
Jan Hubicka writes: > Hi, > this patch lets us to remove > void *mem = __builtin_malloc (s); > if (!mem) > __builtin_abort (); > __builtin_free (mem); > > Where we previously stopped on "if (!mem)" marking __builtin_malloc necessary. > This is done by matching such conditional in tree-s

Re: Implement removal of malloc/free pairs with NULL check

2024-10-31 Thread Andrew Pinski
On Thu, Oct 31, 2024 at 9:08 AM Jan Hubicka wrote: > > Hi, > this patch lets us to remove > void *mem = __builtin_malloc (s); > if (!mem) > __builtin_abort (); > __builtin_free (mem); > > Where we previously stopped on "if (!mem)" marking __builtin_malloc necessary. > This is done by mat

Re: Implement removal of malloc/free pairs with NULL check

2024-10-31 Thread David Malcolm
On Thu, 2024-10-31 at 17:06 +0100, Jan Hubicka wrote: > Hi, > this patch lets us to remove >   void *mem = __builtin_malloc (s); >   if (!mem) >     __builtin_abort (); >   __builtin_free (mem); > > Where we previously stopped on "if (!mem)" marking __builtin_malloc > necessary. > This is done by

Implement removal of malloc/free pairs with NULL check

2024-10-31 Thread Jan Hubicka
Hi, this patch lets us to remove void *mem = __builtin_malloc (s); if (!mem) __builtin_abort (); __builtin_free (mem); Where we previously stopped on "if (!mem)" marking __builtin_malloc necessary. This is done by matching such conditional in tree-ssa-dce.cc and playing same game as we