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
> 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
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
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
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" :)
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
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
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
> > 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
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
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
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
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
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
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?
>>
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
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.
> 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
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
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
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
>
> 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
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
> >
> > 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
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
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
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
> 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
>
> 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
> 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();
> > }
> >
> >
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
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)
>
> 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
>
> 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)
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
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
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
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
38 matches
Mail list logo